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In this Issue 



The components of a typical telecommunications network usually come from 
different vendors and the networks are usually distributed geographically. To 
manage these large-scale networks, a standards-based telecommunications 
network management system must be in place. Standards define the interfaces 
that enable telecommunications equipment manufacturers, system integrators, 
and service providers to develop network management applications that allow 
their products to interoperate in a heterogeneous telecommunications network 
environment. These vendors need a development platform and a toolset to take 
care of the underlying standards-compliant requirements for management 
applications. 

The first nine articles in this issue describe HP products targeted to meet the needs of telecommunications 
application developers. The article on page 6 introduces the HP OpenView Distributed Management (DM) 
Platform, a software foundation that provides the services for building standards-compliant telecommu- 
nications management network applications. The article describes the Telecommunications Management 
Network (TMN) from ITU-T (International Telecommunications Union-Telecommunications), the features 
of the OSI-based version of HP OpenView DM, and the architecture of the new CORBA-based version of 
the HP OpenView Platform. CORBA (Common Object Request Broker Architecture) is a service that en- 
ables objects to make and receive requests and responses in an object-oriented distributed environment 

Developers creating applications to run in a distributed, heterogeneous telecommunications environment 
should not be concerned about what system their applications may be running on. They should be able to 
target their applications to run on a software architecture that handles all telecommunication management 
and control functions for distributed applications. The article on page 17 describes the HP Distributed Pro- 
cessing Environment, which provides infrastructure services that facilitate rapid development, deployment, 
and management of distributed applications in the telecommunications arena. 

Network management relies on information, especially information from network elements such as 
bridges, routers, servers, and gateways. The article on page 22 describes the HP Open Element Man- 
agement Framework (OEMF), which is the implementation of the ITU-T recommendation that covers fault 
management, performance management, and other third-party applications. OEMF makes possible the 
detection, isolation, and correction of the abnormal operation of a telecommunications network. OEMF 
includes the HP OpenView Fault Management Platform (FMP), which is a platform and utility tool for 
managing alarms from multivendor devices and network element managers. 

When a fault occurs in a telecommunications system it can cause an event storm of several hundred 
events per second for tens of seconds. HP OpenView Event Correlation Services (ECS) helps operators 
determine the underlying cause for the thousands of events presented to them. ECS is made up of two 
components: the ECS engine, which executes a set of downloaded rules that control the processing of 
event streams, and the ECS Designer, which enables interactive development of correlation rules. ECS is 
described in the article on page 31. 

TMN uses an object-oriented paradigm, and its management principles are based on the OSI (Open Sys- 
tem Interconnection) standard. Thus, in the TMN model, network and system resources are modeled as 
objects, called managed objects. Telecommunications management application developers need to 
specify and model these managed objects to create management applications. The article on page 43 
describes the HP OpenView GDMO (Guidelines for the Definition of Managed Objects) Modeling Toolset, 
which is an integrated set of tools that enable developers to use a graphical user interface to specify 
and create a file containing managed objects. GDMO is an ITU-T recommendation that defines how 
network objects and their behavior are to be specified. 

Once the developer has created the GDMO specifications for the managed objects, the next step is to 
develop agent applications that maintain and provide access to the objects and the manager applica- 
tions that manage the network through request and response processing. This is the agent/manager 
model of network management. The HP OpenView Managed Object Toolkit (page 52) uses the contents 
of the GDMO specification file to automatically generate OSI-conformant executable agent applications. 
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The toolkit also provides a C++ interface that encapsulates the complexities of the underlying protocols, 
providing assistance in the development of management applications. 

The managed objects are stored in a database called the Management Information Base IMIB). The 
objects in the MIB are defined by GDMO, organized hierarchically, and related by containment. Under- 
standing this data and the operations required to access it are essential for developers implementing 
TMN management applications. The article on page 62 describes a prototype that addresses some of 
the requirements of TMN application developers by allowing them to explore the available management 
data and make enough sense of it to construct and deploy pieces of management applications. 

Once the manager and agent applications have been created, the next step is to test both of these applica- 
tions simultaneously. To help with this task, the new HP OpenView Agent Tester Toolkit (page 771 generates 
tests that allow a developer to execute these tests individually or as a set During agent development, the 
Agent Tester Toolkit is used to simulate requests sent from a manager, transmit these requests over the 
network to the agent, and then receive and process the responses from the agent. 

The TMN architecture defines five network management layers in which telecommunications applications 
can tit. The two top layers are called the business management layer and the service management layer. 
The business management layer contains (unctions that are responsible for the whole enterprise, such 
as budgeting and product planning, and the service management layer contains functions that are 
responsible for managing services provided to customers, such as service transactions and billing. The 
article on page 70 describes an application called HP OpenPM, which fits into these two layers. HP 
OpenPM is an open, enterprise-capable, object-oriented business process flow management system 
(BPFM). HP OpenPM is a middleware service that provides the enabling technologies for defining and 
managing workflow in areas such as resource allocation, task initialization and data exchange, and end- 
to-end communication and security. 

Telecommunications networks and distributed computing environments rely on reliable and consistent 
storage management strategies. Today, storage management strategies involve more than just more disk 
drives. They also include storage management and different types of storage devices for offline, nearline, 
and online data storage. The article on page 81 provides an overview of HP hardware and software 
products, services, and partners that provide storage management solutions. 

Even though processor speeds continue to improve dramatically, they are barely keeping up with the 
increasing numbers of concurrently running applications and CPU-intensive applications with higher 
throughput requirements. Additionally, as the number of interconnects between systems and I/O devices 
continues to increase, I/O channels become bottlenecks to system performance. For all these reasons, 
today's parallel bus architectures are reaching their limits. In the search for a higher-performance serial 
interface, HP chose Fibre Channel because it overcomes the limitations mentioned above by supporting 
sustained gigabit data transfer rates The article on page 99 describes Tachyon, which is HP's gigabit 
Fibre Channel chip. The article on page 94 presents a technical description of Fibre Channel. 

C.L Leath 
Managing Editor 
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A Platform for Building Integrated 
Telecommunications Network 
Management Applications 

Telecommunications companies today are faced with rapid technological 
change, large heterogeneous environments, and a greater need to provide 
customers with products that ensure reliable, cost-effective network 
service. This means that these companies need a platform that has a 
visionary strategy that enables them to develop standards-compliant 
network management solutions for a continually changing environment. 

by Prabha G. Chadayammuri 



The telecommunications industry is going through phenome- 
nal growth and change. This growth has made telecommu- 
nications networks essential to the daily activities of the 
enterprise and individuals. It has also given rise to the need 
lor better ways to manage and mainUiin heterogeneous and 
inuliivendor networks. 

Network management includes the operations, administra- 
tion, maintenance, and provisioning (OAM&P) functions 
requited to monitor, interpret, and control a network and 
the services it. provides. When net works started to be used 
beyond the academic community and before deregulation 
and privatization of the telephone Industry, there were fewer 
vendors, thus fewer multivendor management issues. Also, 
the rate of introduction of new network technologies was 
much slower. These conditions meant that network manage- 
ment could be ad hoc and vendor-specific. Today, issues 
such as multivendor networks and equipment, the need lo 
automate certain network management tasks, and the rapid 
integration of new technologies have driven the need to 
standardize telecommunications network management. 

Since the early UlSOs, the Standardization bodies have been 
developing and specifying a collection of standards for 
managing telecommunications networks. A portion of these 
standards, dealing with open systems, is contained in the 
X.7xx series of standards defined by the ITU-T tintema- 
tional Telecommunications Union — Telecommunications). 
Another series of standards, the M.3xxx series from ITU-T, 
defines a model known as the Telecommunications Manage- 
ment Network (TMN). 1 

T.YIN is based on the Open Systems Interconnection (OSI) 
systems management model, which is set of standards thai 
define the rules for processing and transferring data over 
networks.- Such systems are called open systems. Although 
not intrinsically pail of TMN. OSI systems management stan- 
dards were developed jointly by the ISO and ITU standards 
bodies. 

All of these standards, no matter how worthy, are simply 
collections of well-written guidelines without a platform and 
tools to build network management solutions. Choosing a 



network management platform is a critical strategic deci- 
sion that has long-term implications. The development of 
large-scale telecommunications management systems 
requires a significant investment of resources. Solutions, 
once deployed, will be supported for many years. 

For equipment manufacturers and systems integrators, the 
network management foundation must enable rapid devel- 
opment of applications that can differentiate and add value 
to their products. For telecommunications service providers, 
the network management foundation must enable rapid 
deployment of new services that improve competitiveness 
and new operations that increase efficiency. 

HP Open View products provide the platform and enabling 
technologies required for network management solutions 
for today's telecommunications environment. 

IIP OpenView DM 

The HP OpenView Distributed Management ( DM) platform 
is a software platform for designing portable, standards- 
based systems for telecommunications management (see 
Fig. 1 ). HP OpenView DM products are focused on meeting 
the reliability, performance, distribution, and standards 
needs of telecommunications equipment manufacturers, 
service providers, and system integrators. The IIP OpenView 
DM platform offers the following features for developing 
TMN applications, 

Standards Support. The HPOpettVIew DM products support 
protocol, object, and service specifications defined by ITT". 
OSI. X/Open " , the Internet Engineering Task Force (IETF) 
for SNMP (Simple Network Management Protocol), and the 
Network Management Forum (NMF). :I 

There is also full support for network management protocols 
CMIP (Common Management Information Protocol), RFC 
1006 (TCP/IP), and SNMP. 4 * 

Open Systems. The IIP OpenView DM platform is built on an 
open systems architecture, enabling solutions to ran on a 
variety Of hardware platforms. Native support is implemented 
for IIP SI000 workstations and serv ers running the HP-UX* 
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operating system anil Sun SPARC workstations running the 
Solaris and SunOS operating systems. Support for HP Open- 
View is also provided on oilier hardware and software plat- 
forms. 

Postmaster. The postmaster serves as the integration point 
for management protocol stacks such as CMIP and SNMP, 
management APIs, and related facilities (e.g., routing, 
events, and association control), 'lite postmaster provides 
distributed message routing and access lo applications and 
services through standard management protocols. Finally, 
the postmaster reliably Creates and manages associations 
(conned ions), maps objects In network addresses and pro- 
tocol slacks, ami routes requests from manager systems and 
responses from managed systems (agents). 

Event Services IIP I ipenView DM provides a set of services 
thai management applications can use lo control evettl anil 
alarm messages from diverse network elements and systems 
ll includes a mediation service thai collects, stores, fillers, 
and extracts messages and an alarm management service 
thai displays and correlates alarm messages and invokes 
external applications based on alarm data. Alarm manage- 
ment and event correlation services are described in the 
articles on pages L!2 and :!l respectively. 

HP Distributed Processing Environment (DPE). The IIP DPE 

provides an Information Networking Architecture UNA) 
compliant platform for telecommunications services aftd 
operations systems. Trader services and an API framework 
simplify the development and deployment of distributed 
telecommunications applications. IIP DPF. is described In 
the article on page 17. 

Graphical User Interface. The IIP < ipettView windows graphical 

user Interface (GUI) provides network operators ami admin 

isltalots with a consislenl view of Hie managed environment 



and seamless integration of management functions, regard- 
less of vendor or managed object type. HP Open View win- 
dows provides a common interface that simplifies the devel- 
opment and use of management applications. Finally, the 
IIP i tpenView windows GUI is the key integration point for 
IIP ( IpenView applications. 

Modeling Toolset. The I IP Open View GDMO (Guidelines for 
the Definition of Managed Objects)' 1 Modeling Toolsel is an 
integrated suite nl software lools for designing and analyzing 

objects used in network management applications. GDMO is 

an I Si ) standard Ihal describes a consislenl methodology for 
specifying managed objects in TMN applications. 

The HP Open View GDMf ) Modeling Toolsel has a forms- 
based fill lhal enables developers to create GD.VH ) specifi- 
caiions and export Ihem as ASCII files for use by the next 
application in the tool chain, the Managed Object Toolkit. 
The IIP Open View GI)M< > Modeling Toolset is described in 
the article on page h'l. 

Managed Object Toolkit. The IIP Open View Managed Object 
Toolkit is a C++ code generator ihal accelerates the devel- 
opment of GDM< ( based manager and agetti applications 
(described below). The managed object toolkit includes an 
infrastructure ihal provides a collection of reusable objects 
thai handle CMIS Operations such as GET, SET. and ACTION. 

Agent application development Is unproved because lite 
Managed Object Toolkit takes the GDMO ASCII file and 
automatically converts the GDMI > specification into ;ui 
• iSI-conformanl. executable agent. The Managed I tbjecl 
Toolkit is described in the article on page : ">- 

TM\ Applications and IIP OpenView 

IIP i tpenView products have been adopted by many juomi- 
nenl equipment manufacturers and lelecommiinicaiions 
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service providers to implement a variety of TMN solutions. 
Some of the areas in which TMN applications can lie built 
upon the III' Open View foundation include: 

• Services management lor broadband networks Including 
Synchronous Optical Network (SONET), Synchronous 
Digital Hierarchy (SDH ). Asynchronous Transfer Mode 
(ATM), and residential services such as video-on-demand 

• Provisioning and monitoring applications for broadband 
networks 

■ Network monitoring for outsourced customer networks 
managed by telecommunications Service providers 

1 Customer gateways into public networks for real-time moni- 
toring and data management 

1 Integration with other management platforms for TMN com- 
patibility and a single view from a nuillivcndor environment 
Element management systems for new equipment and new 
data communications services. 

The IIP ( ipenView DM platform has traditionally supported 
the OSI systems management model to provide TMN solu- 
tions. However, in recent years the Common Object Request 
Broker Architecture (CORBA) 7 from the Object Management 
Group (OMG) has attracted interest as a general model for 
distributed application development. 

The combination of the CORBA and < )SI models is an ex- 
tremely powerful solution for TMN application development. 
Thus, HP Open View DM platform development is moving in 
that direction. 

The rest of this art icle will discuss various aspects of the 
TMN architecture and the OSI model and their relationship 
to the existing OSI-based HP OpenView DM platform and 
the evolving CORBA-based platform. 

TMN Architecture 

Fig. 2 shows the business, service, network, and element 
management layers of the TMN model and the interaction 
between applications in these different management layers. 
The functionality of applications in each of these layers is 
defined in ITC-T Recommendation M.30T0. 1 

Network Element Layer. Functionality at this layer is prov ided 
by the network elements (e.g., switches, multiplexers, 
repeaters, hubs, terminals, etc. ). These functions include 
operations such as performance data collection, alarm 
collection, protocol conversion, and so on. Applications at 
this level are responsible for managing network elements. 

Element Management Layer. Finn lions at this layer are respon- 
sible fey managing a subset of network elements, performing 
as a gateway to network elements in the upper layers, and 
keeping statistical and historical information about network 
elements. 

Network Management Layer. Net work management functions 
are used to support TMN applications that require a global 
view of the network. Data for this global view is collected 
from data summarized by the network element management 
layer. This layer is also responsible for the technical provi- 
sion of services requested by the service management layer. 

Service Management Layer. This layer is responsible for man- 
aging 'he services provided to customers. It provides the 
point of contact with customers for all service transactions. 



including billing, quality-of-scrvice (QoS) data service con- 
tracts, and so on. 

Business Management Layer. This layer contains (unctions 
that are responsible for the whole enterprise. These func- 
tions include goal setting and budgeting, product planning 
and definitions, and agreements between jurisdictions. 

Operation Systems and the Manager/Agent Model. The opera 
lions systems shown in Fig. 2 are integrated telecommunica- 
tion management applications that implement the network 
management functions in the TMN layers. The operations 
systems are based on an agent/manager model. This model 
resembles the clientyserver paradigm in which applications 
in the manager role are clients and applications acting as 
agents would be seivers. The agent/manager model is also 
called a managed system (agent ) and managing system 
(manager) architecture in TMN terminology. The agent/man- 
ager model is based on using objects to model the system 
being nuuiaged. Each object can have attributes that repre- 
sent its state or relationship with other objects, its special- 
ized behaviors (called actions), and notifications it issues to 
signal some event. Thus, an object encompasses a device's 
behavior as well as its physical characteristics. An agent 
resides in an object and reports the Object's status to the 
manager. The manager, equipped wiih the capability to 
have a global view of the network, manages the agents and 
handles the notifications from agents. 

Q3 Interfaces. I Operations systems within and between TMN 
layers are required to use a set of standard interfaces called 
Q3 interfaces for the exchange of management informa- 
tion. 81 ' Q3 interfaces are responsible for connecting ail op- 
erations system to a network element, an operations system 
to a Q adapter, an operations system to a mediation device, 
or two operations systems in the same TMN. specifica- 
tions use the Common Management Information Service 
Element ( ( ' M ISE ) protocol 10 for management and the file 
transfer access and management (ftam) protocol for bulk 
transfer. 

The standard way to convert a non-TMN function into a TMN 
function is called a Q adapter. Loosely stated, Q adaption 
is a translation between Q.'J and the non-Q3 models at run 
time. Translation to a level less than Q.'3 requires a mediation 
device to raise the adaption to Q3 levels. The X reference 
points in Fig. 2 also perform an interface function. They pro- 
vide an interface for communications with operations sys- 
tems belonging to other TMNs or between TMN operations 
systems and non-TMN operations systems on other TMNs 
that support TMN-like interfaces. Q3 interfaces are generally 
regarded as appropriate for the X reference point. 

The HP OpenView DM platform supports the APIs and proto- 
cols necessary for TMN applications. The HP OpenView DM 
platform provides the Q:J interfaces via the X/Open manage- 
ment XOM/XMP APIs and the C++ classes generated by the 
Managed Object Toolkit described in the article on page 52. 
Faster APIs like the BER ( Basic Encoding Rules) Manage- 
ment Protocol (BMP) and the generic data type dictionary 
APIs are available on the platform." Application developers 
can build OSI applications using the APIs or the Managed 
Object Toolkit. The Managed Object Toolkit generates a 



8 i Wober 1996 i lewtet L-Packard Journal 

©Copr. 1949-1998 Hewlett-Packard Co. 



Business 
Management 
Layer 



Service 
Management 
Layer 




Operations 
Systems 



^^^^ ^^^^^ 



To or trout 
other TMNs 



Element 
Management 
Layer 



Network 
Management 
Layer 



Network 
Elements 
Layer 




Fig. 2. TMN archilc.ct.re sh.mi.rg the network numagement layers and various TMN elements in each layer. 



complete application skeleton that c an be customized by 
adding user-defined behaviors. 

The OS1 Model 

to mentioned earlier, TMN is based on the OSI model mid the 
I ir open View DM platform supports the OSI model. In OSI 
system management, managed object classes are defined 
using (iDMO (Guidelines for the Definition <>i Managed 

. ,i ,si. A managed object class has its state and relation- 
ships will, other objects represented in its attributes, which 
can be accessed by GET and SET methods. The managed 



object class definition can have complex interfaces called 
actions and can specify notifications, which are emitted 
signal events associated with the object. 

Abstract Syntax Notation One (ASN.l), 12 a data definition 
language, is used to describe the syntax of management data 
exchanged between objects. Behavior templates ate used ... 
define the semantics of operations on attributes and objects 
and are commonly expressed in natural languages. Ma 
result, there is no standard way of parsing the behavior 
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templates, TJie agent developer is allowed In implement the 
behaviors appropriately. 

A managed object can be created or deleted by external 
commands if allowed by the object's GDMO specification. 
GDMO allows multiple inheritance, in which a given object 
can inherit all the operations, notifications, and behaviors of 
Other objects. References 13, 14, and 15 provide many of the 
widely used objects, attributes, and notifications used in 
network management. 

When defining new objects, these standard definitions are 
expected to be reused whenever possible. This is one of 
the challenging aspects of OSI object modeling. The GDMO 
Modeling Toolset, available on the IIP ( ipenView DM plat- 
form, makes this task much easier. The article on page 43 
describes the GDMO Modeling Toolset. 

Management Interactions 

Fig. 3 shows the seven-layer OSI reference model 2 Each 
layer has a clearly defined role in the transfer of information 
over a net work. P( >r systems management, the application 
layer is of the greatest interest. Applications intemperate 
with each oilier using application service elements (ASEs). 
which are defined by I he application layer. The Common 
Management Information Service Element (CMISE), the 
Remote Operations Service Element (ROSE), and the Asso- 
ciation Control Seivice Element (ACSE) are the most impor- 
tant ASEs used for systems management. The protocols 
used to implement these service elements are also defined 
as pail of the ISO standard specifications. 



OSI systems management operates like the agent/manager 
model described above. An application issuing management 
Operations and receiving notifications is said to be acting in 
the manager role, and an application performing iiianagenjenl 
operations and emitting notifications on behalf of managed 
objects is said to be acling in the agent role. An open system 
is made up of managed objects and the various processes 
involved in processing and transferring information. 

A manager is expected to establish an association with an 
agent using the ACSE before attempting any management 
interaction. If the association goes down, both parties can 
delect it. When the association is set up, the manager and 
the agent exchange management information about their 
respective capabilities, including authentication schemes, 
encoding schemes, maximum data sizes, multiple object 
selection capabilities, and so on. These capabilities are 
called functional units. The HP Open View DM platform sup- 
ports both direct user control over association management 
and the automatic connection management mode in which 
the user does nol have to be directly involved in the associa- 
tion management. 

Once the association is set up between a manager and an 
agent, management informal ion can be exchanged. The 
manager is allowed to perform CREATE, DELETE, and ACTION 
operations Ofl the managed objects and GET and SET opera- 
tions on their attributes as defined in their GDMO specifica- 
tion. The agenl performs the operations on the managed 
objects on behalf of the manager and sends replies back to 
the manager. 
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The managed objects emit POtjflcafiMtt (events) specified in 
their C.DM< ) Specifications. Notifications usually signify 
something of interest happening at the object, like its cre- 
ation, deletion, or attribute value change. The agents deliver 
the notifications either directly to the manager or indirectly 
through event forwarding discriminators, which are managed 
objects that filter events coming from agents This filtering 
ensures that only events of interest are received by the man- 
ager. The OSl-based HI' < )penView DM platform sup|>orts 
the most generic form of pvent discrimination available 
today. 

Another important aspect Of OSS system management is that 
it is based on an asynchronous message passing model, as 
are most other network management protocols in use today. 
All Operations c an be classified into four primitives tor 
types): requests, replies, confirms, and indicates. These primitives 
are used in the follow ing way: 

1. To perform an operation, a manager sends a request 
message. 

2. When the message shows up at the agent, it is received as 
an indicate message. 

3. Later, the agent may send a reply message. 

1. The reply message is received at the manager as a confirm 
message. 

The agent sends a reply message if the original request re- 
quired a confirmation. The CMISK GET, CANCEL-GET. CREATE, 
and DELETE operations are always confirmed, whereas the 



SET, EVENT-REPORT, and ACTION operations can either Ih> con- 
firmed or unconfirmed. Request and reply messages are always 
directed outward from the application and indicate and confirm 
messages are always directed inward. 

The Open Protocol Interface Architecture 

Fig. 4 shows the IIP Open View DM postmaster with the 
attached API stacks, protocol slacks, 4 - 5 and intermediate 
stacks. I&I7 |S The postmaster is at the heart of the < )S1- 
based HP OpenView DM platform. Applications bind to the 
postmaster processes running on different nodes. Postmas- 
ters on the different nodes coordinate interactions !>etween 
applications bound to them. 

The HP Open View DM postmaster is built on an architecture 
known as the Open Protocol Interface, which is based on 
Ihe OSI messaging model described above. 

Messages How into Ihe postmaster either through the Al '1 
stacks or through the protocol stacks. The processed mes- 
sages that are sent out and need confirmations are kept on a 
sent queue awaiting confirmations. When the confirm mes- 
sages come in they are matched with the corresponding 
request messages. This store-ancl-forward mechanism 
allows greater reliability in the message delivery. Flow 
control mechanisms are implemented to address congestion 

problems. 

The X/Open management APIs (XOM/XMP) and the I3EH 
Management Protocol (BMP) are the API stacks. These and 
the ( Mil'. SNMP ( RF( ' 1 157 1, and RFC 1006 protocols are 
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Glossary 



This glossary contains definitions of some of the telecommunication 
terminology and acronyms used in many of the telecommunications 
articles in this issue. 

ACSE (Association Control Service Element) In the OSI model this 
is an application-layer protocol thai is used to establish and terminate 
an association between applications on the same system or on different 
systems. 

Agent/Manager Model This model defines the basic architecture for 
network management of distributed systems. (This model is also called 
the managed system/managing system model ) The agent/manager 
system manages devices called managed objects, which represent a 
conceptual view of network resources that need to be monitored or con- 
trolled. The manager's role is to maintain a global view of the network 
and to control, coordinate, and monitor network activity. The manager 
also issues requests for operations to be performed by the agent and 
then receives notifications emitted by the managed objects and sent by 
the agent. The agent's role is to maintain its portion of the MIB, receive 
and execute requests sent from the manager, and send notifications to 
the manager when necessary (see Fig. 1 ). 

ASN.1 (Abstract Syntax Notation One, or ITU standard X.208). 

This is a description language used to define the data types exchanged 
between systems. 

BER (Basic Encoding Rules). A method for encoding data in the OSI 
environment. 

CMIP (Common Management Interface Protocol). This is half of the 
OSI's systems management protocol (the other half is CMIS). CMIP uses 
the agent/manager paradigm to communicate management information 



between systems This protocol differs from SNMP in that it is more 
rigorous, is designed for open systems, and is an association-oriented 
protocol, requiring the two communicating CMIP processes to establish 
an association before sending any management messages. This associa- 
tion is governed by ROSE and ACSE See the article on page 52 for more 
about CMIP 

CMIS (Common Management Information Service). This is the part 
of the OSI systems management protocol that enables management 
applications to communicate in the OSI environment CMIS offers a set 
of services that provide for management operation, retrieval of informa- 
tion, and notification of network events (see also CMIP). See the article 
on page 52 for more about CMIS. 

Containment. In an object-oriented hierarchy, containment defines the 
relationship between a parent object and a child object. 

Contracts. In the context of the Distributed Processing Environment (OPE), 
contracts are the way in which ob|ects in one building block (a software 
package containing several objects) describe their interfaces to objects 
in other building blocks See the article on page 17 for more about con- 
tracts and DPE. 

CORBA (Common Object Request Broker Architecture). This is an 
implementation of the Object Management Group's specification of an 
object request broker An object request broker provides the services that 
enable objects to make and receive requests and responses in an object- 
oriented distributed environment. 

Distributed Processing Environment. This is a platform for managing 
and controlling distributed computing in a TMN network 
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Fig. 1. The agent/manager model. 



all supported by the OSI-based HP Open View DM platform. 
This supjiort. along with the requirements of association 
control and routing, provide the full complement of OSI 
conformance. 

User-defined API stacks and protocol stacks can lie added 
easily to the HP OpenView DM platform using the Open Pro- 
tocol Interface architecture. New API and protocol stacks 
continue to be added by IIP OpenView DM users. This flexi- 
bility allows easy integration of existing legacy ajiphcations 
into the management framework. 
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The intermediate stacks on the OSI-based IIP OpenView DM 
platform are used lo set up associations, determine routes, 
perform event forwarding discrimination, and so on. Each 
message is passed through its configured set of intermediate 
stacks for processing. 

The intermediate stacks can also be used for data concentra- 
tion or other similar purposes. This makes the Open Proto- 
col Interface architecture ideal for building TMN mediation 
devices. For instance, the Event Correlation Senil e stack 
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GDMO (Guidelines for the Definition of Managed Objects). These 
guidelines define how network objects and their behavior are specified 
For example. GDMO can be used to specify how a certain system com- 
mand Isoftware object) should behave when executed See the article on 
page 43 for more about GDMO 

Managed Object This is a conceptual view of a logical or physical 
resource that needs to be monitored and controlled to avoid network 
failure and performance degradation A managed object is defined in 
terms of us attributes, operations that can be performed on it. notifica- 
tions it may emit, and its relationship with ether objects. 

MIB (Management Information Base). This is a structured colli! 
of managed object instances and their attributes. See the article on 
page 67 for more about the MIB 

Mediation Device. This element of theTMN architecture is responsible 
for protocol conversion, information conversion and storage, data buffer- 
ing, and filtering. This is probably the most vaguely defined element in 
TMN and its functions are sometimes implemented in a 0 adapter 

Network Elements (NE). Tnese elements represent the devices that 
make up a telecommunications network It is assumed that an NE is 
"'intelligent" enough to have the possibility of generating and transmit- 
ting some kind of information useful for network management (alarms, 
status, etc.) All NEs produce for external use some sort of internal 
alarms, both urgent and nonurgent These alarms are representative of 
internal faults. Urgent alarms indicate a need for immediate mainte- 
nance. Network elements play the role of managed objects in the agent/ 
manager model The article on page 6 contains more about network 
elements 

OAM&P (Operation, Administration, Maintenance, and Provision- 
ing). These are the functions required to solve the complex problem of 
providing telecommunications network management. 

OMG (Object Management Group). This is a nonprofit international 
corporation made up of a team of dedicated computer industry profession- 
als from different corporations working on the development of industry 
guidelines and object management specifications lo provide a common 
framework lor distributed application development. 

Operations Systems (OS). These are the applications where network 
management takes place They can be thought of as supervisory or con- 
trol systems that receive a large amount of data from the network and 
provide for its elaboration and for the generation of data useful for man- 
agement purposes The article on page 6 contains more about opera- 
tions systems 



Q Adapter. This is a TMN element that is used to connect a TMN sys- 
tem to a non-TMN system The article on page 6 contains more about Q 
adapters. 

03 Interfaces. These are a set of interfaces used within and between 
layers m the TMN architecture to exchange management information 03 
interfaces are responsible for connecting an operations system to a net- 
work element, an operations system to a Q-adaptei. an operations sys- 
tem to a mediation device, or two operations systems in the same TMN 
The article on page 6 contains more about 03 interfaces. 

ROSE (Remote Operation Service Element). : OS! 

service that allows applications to invoke request and reply interactions 
with applications on remote systems The article on page 6 contains 
more about ROSE 

SNMP (Simple Network Management Protocol). This is TCP/IP 
protocol that defines how to manage a network SNMP uses the agent/ 
manager model to monitor and administer the network SNMP is based 
on a connectionless protocol, which requires no established connection 
between manager and agent before transmission 

Trader Service This is a matchmaking service for clients and servers in 
a Distributed Processing Environment. A server registers its capabilities 
m the form of a contract with an entity called a trader, and when a client 
needs a capability in a certain contract type, it uses the trader service 
to find the server lhat has the particular capability See the article on 
page 17 for more 

Telecommunications Management Network (TMN). TMN. which is 
defined in ITU-T Recommendation M.3010, is a management commu- 
nications concept that defines the relationships between basic network 
building blocks (network elements, different network protocols, and 
operations systems) in terms of standard interfaces See the article on 
page 6 for more about TMN 

XMP (X/Open Management Protocol), This protocol provides the TMN 
application developer with a C language interface to the underlying 
CMIS/CMIP and SNMP protocol services XMP APIs use XOM objects as 
parameters. See the article on page 52 for more 

XOM (X/Open OSI Abstract Data Manipulation) A C language inter- 
face designed for use with application-specific APIs that provide OSI 
services, such as X 400 and CMIS XOM APIs provide functions for 
accessing managed objects and shield programmers from the complexi- 
ties of the ASN 1 data types in the MIB See the article on page 52 for 
more. 



on the postmaster performs event correlation for ev ents that 
pass through the slack. 

Adding Intermediate stacks is relatively trivial This allows 
extreme flexiliility in customizing the plat form for specific 
needs. Consider, for instance, how user-defined security 
might he added to the platform. The < (pen Protocol Interface 
architecture presently allows security information lauihcnli- 
caiion token and authorization data) to he specified in each 
message. Today such information is regarded as opaque and 
is nof interpreted by die slacks, if a user-defined intermedin 
ale security slack were added lo Hie |>lalform, the security 
informal ion in the messages could he iiilercepted. The user 



slack could interpret the informal ion and accept or reject 
the message, im|>lemeniing user-specific hehaviors. 

The Open Protocol Interface development kit is separately 
available as an IIP product. 

Naming and ( lontainmenl 

To perform the operations and actions described above, 
t here has lo he a way of addressing the object instances. In 
OSI system management, each object instance has to have a 

Unique name, known as the object's tlisthiuiiishctl name. 
The uniqueness of the name is guaranteed by naming all 
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objects with respect tG a Containing Object or its parent in- 
stance. The only (virtual) object not contained in another 
is called the root. The relationship between the parent 
(superior) object and the child (subordinate) object is called 
containment 

Since every object instance (except root) is contained in its 
parent instance, an acyclic, hierarchical tree of object in- 
stances can be constructed. This is known as a containment 

live. The idea of collecting objects based on containment is 
particularly useful in defining operations that apply to multi- 
ple objects. Such operations are called scoped operations in 
OSI systems management terminology, The CMISE GET, SET. 
DELETE, and ACTION operations can be scoped and result in 
the operations being applied to all objects that tall within 
the specified scope. Multiple object selection and actions 
make the OSI system management model far more powerful 
(and complex ) than simpler models like SNMP. 

The object instance name Ls required in all CMISE trans- 
actions. When automatic connection management is used, 
the IIP Open View DM postmaster uses a service called the 
Object registration service to identify the target application 
for each request from its instance name. The object registra- 
tion Service allows users to configure the object location 
externally, enabling one to build highly scalable systems that 
provide complete location transparency. 

Naming and containment are described in more detail in the 
article on page 52. 

CORBA-Based Application Development. 

So far, we have gone over the standards support and other 
features of the OSI-based HP Open View DM Platform. Since 
most telecommunication resources today are modeled using 
a GDMO specified object, these applications tend to be in 
the element management layer of the Telecommunications 
Management Network . 

As we move up the TMN hierarchy (Fig. 1), the need for 
greater distribution, reliability, database access, and user 
interface access become obvious. TMN standards do not 



const lain the internal structure i if applications. As a result, 
several nonstandard models are in use that need to be inte- 
grated into a single model to reduce costs. 

The new HP Open View telecom management platform 
addresses these specific issues with the use of the Common 
Object Request Broker Architecture (f'ORBA) from the 
Object Management Group (OMG). CORBA provides a 
highly scalable distributed object model. The OMG has a 
large industry participation and addresses all aspects of 
object modeling. 

The new IIP Open View telecommunication management 
platform uses the IIP ORBPlus distribution backplane for 
application interactions. IIP ORBPlus supports the standard 
HOP and DCE CIOP transports as well as a highly optimized 
local procedure call mechanism. 

The OMG Common Object Service Specifications (COSS) 19 
define a basic event service. Even though this service is im- 
plemented on the HP Open View platform, it is not sufficiently 
robust for telecommunications management applications. 
IIP Open View, therefore, has developed a CORBA-based 
notification service.-" which allows users to register with 
a notification manager for events filterable on multiple 
attributes. 

The CORBA-based IIP Open View telecom platform also 
comes with t he OMG naming and life cycle services, the 
OMG standard transaction service, and a location service, 
called the trailer serriee. The collection of CORBA compo- 
nents and services, known as the IIP OpenView distributed 
object infrastructure, is shown in Fig. 5. 

The notification service for the distributed object infrastruc- 
ture provides the same value in the CORBA-based platform 
as the OSI evenl-forwarding discriminator does in the OSI- 
based platform. The event-forwarding discriminators imple- 
mented on the HP OpenView DM platform are more suitable 
for Q3 notifications. 
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The CORBA-based OpenView plalfomi also provides a more 
scalable version of the relationship service known as the 
to|iology service anil a database strategy based on the indus- 
try standard ODBC (Oj>en Datalia.se Connectivity ) interfaces. 
Tlie topology service enables the developer to define rela- 
tionships between topological entities, which are the ab- 
stract objects corresponding to the elements in a network. 
The 01 »B< interlace is a transparency layer that the \'( >pen 
Consortium developed to allow access In relational data 
bases. This API allows a great degree of independence front 
specific databases, with a trivial performance loss. 

With i he availability of a CORBA-based platform, application 
development is made considerably easier. Object modeling 



is done in IDL. the OMG's Interface Definition Language. IDL 
has the same capabilities as GDMO and ASN. 1 combined. 21 
Also, the CORBA-based platform allows operations on 
remote objects to be just as easy as operations on local 
objects, although local object access would be faster. 

In the model shown in Fig. G. CORBA-lwised applications 
access Q3 and other objects using adapters, or HP Open- 
View DM APIs. Q9 adapters can be generic adapters that 
provide a CM1P interface in IDL,— adapters tliat follow the 
mappings from the .VOpen Joint Interdomain Management 
(JIDM) task forced 1 or class-specific adapters that expose 
modified JIDM interfaces.-' 



Business 
Management 
Lave. 



Sell 
Management 



Service 
Management 
Laver 




Presentation Framework 


HP 
OpenView 


Modeling 
Tools 



Data 
Framework 



Distributed Object Infrastructure 
(ORB + CORBA Services) 




T t * 



Open Protocol Interface 



T I T 



Open Protocol Interface 



Legacy 03 
Adapter Adapter 

i T_ 



To Legacy Services 



■ ■ 


To or from 
other TMNs 


A ^ 


X Reference 
Point 


Presentation Framework 


Security I 


HP Modeling 
OpenView Tools 





Soil 
Management 



Network 
Management 
Layer 




Presentation Framework 




Security 


HP Modeling 
OpunView Tools 





Self 
Management 



Semantic 
Processes 



Oata 
Framework 




Semantic 
Processes 



Data 

fi.imeworl. 



Distributed Object Infrastructure 
I0RB ■+■ CORBA Services! 



Distributed Object Infrastructure 
(ORB-t- CORBA Services) 



* 7 



Open Protocol Interface 



Open Protocol Interface 



Open Protocol Interface 



Open Protocol Interface 




To Legacy Services 



Fin. o. tmn applications built with COHBA accessing QSand othefdbjed Ids, 

© Copr. 1949-1998 Hewlett-Packard Co. 



Oetobei L966 Hewlett Packard Journal 16 



Tile JIDM adapters can be sialic or dynamic. The sialic 
adapters are built for specific GDMO Management Informa- 
tion Bases (MIBs) and are expecled to offer better perfor- 
mance. The dynamic adapters use (he generic facilities of 
the < ORBA architecture ( 1)11 and DS1 ). which are more flex- 
ible lhan the sialic interfaces. The JIDM activity produces 
mappings for Ct >RBA-Q3 interaction and CORBA-SNMP 
interaction. The C'ORBA-based IIP ( )penView platform will 
supply adapters after the standards in this area have stabi- 
lized. The Open Protocol Interface architecture discussed 
before is ideally suited for building Q-'i and SNMP adapters 
to CORBA. 

With the use of adapters, all other object models appear lo 
be CORBA objects to the application developer. Applications 
use CORBA to gain distribution, standard language mappings, 
and common object services for portability and the topology 
services for data integration. The ODBC layer supports 
transparent access to multiple databases. In addition, a suite 
of enterprise management lools are available from oilier HP 
organizations that greatly enhance CORBA-based application 
development. 

Summary 

The new IIP ( ipenView telecom platform combines the power 
of the CORBA model with the support for OS1 management 
standards. As SNMP-bascd management gains acceptance in 
the telecom industry, the HP OpenView SNMP-based man- 
agement platform will be integrated Into the above model. 

For pure Q3 access, developers today are encouraged to use 
the OSl-based HP OpenView DM platform. Q adapters, medi- 
ation devices, Q3 manager applications, and Q3 agents usu- 
ally found in IheTMN element management and network 
element layers fall into this group. 

For highly scalable distributed applications requiring trans- 
action processing, user interfaces, database access, and 
greater control over the quality of service usually found in 
the TMN network and service layers, developers should use 
the CORBA-based HP < IpenView telecom platform. 
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Distributed Processing Environment: 
A Platform for Distributed 
Telecommunications Applications 

Vendors developing applications for a heterogeneous, distributed 
environment need to be able to build towards a platform that integrates 
all the management and control functions of distributed computing into a 
unified software architecture that allows their applications to be available 
from any point in the network regardless of the system or geographic 
location. 

by Frank Leong, Satya P. Mylavarabhata, Trong Nguyen, and Frank Queniada 



Tlif IIP Distributed Processing Environment (DPE) provides 
infrastructure services thai facilitate the rapid development, 
deployment, and management of distributed applications in 
the telecommunications arena. DPE is a key component of 
the Telecommunications Information Networking Architec- 
ture (TINA), an architecture for multimedia networks that 
emphasizes distribution and interoperability of telecommu- 
nications applications. TINA is an evolving architecture and 
is governed by the TINA Consortium (TINA-C), which is a 
project sponsored by 40 leading telecommunications and 
computing companies. The project's aim is to find a way to 
integrate all telecommunications management and control 
functions into a unified logical software architecture sup- 
ported by a single distributed computing platform. 

This paper describes the architecture and components that 
make up IIP DPE. a product that is compatible with (and 
will evolve with I the TINA specifications. 



of several objects and can be installed and modified inde- 
pendently of other building blocks in the network. Building 
blocks interact with one another via interfaces called 
Contracts. Contracts are the exposed interfaces of an object 
in that they are used for communication between building 
blocks. They are also backward compatible to ensure inter- 
operability between software objects contained in multiven- 
dor building blocks. Contracts are subject to authentication 
and access control checks. 

A building block can he a server or a client or both. A server 
must offer one or more contracts to allow clients to interface 

TMN Layers 
Business 

Management I I • • • I 

Layer 



INA. TINA, and DPE 

IIP DPE and TINA have a common root in the Information 
Networking Architecture (INA). which was originally devel- 
oped at Bellcore. TIN As architecture specifies a distributed 
processing environment based on the original INA DPE 
specifications. IIP DPE provides key infrastructure services 
for INA and TINA. 

INA defines a methodology and framework for developing, 
providing, and maintaining highly distributed systems, char- 
acteristic of the next generation of communications environ- 
ments. INA leverages and combines the efforts of multiple 
standards bodies, research organizations, development 
organizations, and consortia (e.g.. TMN. OSCA, OSF/DCE, 
O.Mli CORBA. OSI/NMF. etc.). Fig. 1 shows the relationship 
between INA DPE and the TMN (Telecommunications Man- 
agement Network) model. TMN is described in the article 
on page 6 and the DPE services are described later in (his 
article. 

INA applications anil services are deployed as software 
modules railed built/illy Murks. A building block is made up 
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and make use of its services. In the DPE architecture (de- 
scribed below ), applications are modeled as building blocks. 
The DPE itself is made up of server building blocks (e.g., 
contract trader, repository, etc.) which offer contract inter- 
faces to application client building blocks. 

The INA structure enables distributed software building 
blocks from multiple suppliers to interoperate. This distrib- 
uted object computing results in faster software develop- 
ment since there is greater software reuse and modularity in 
design. 

hi summary, INA is a framework for interoperability, porta- 
bility, and network resource management. The following 
goals have been established for INA: 

• Rapid and flexible introduction of new services 

• Reuse of software modules 

• Use of general-purpose solutions 

• Multivendor hardware and software solutions 

• Independence of applications from the transport implemen- 
tation technology 

• Separate transport technologies from higher-level control 
and OAM&P (operation, administration, maintenance, and 
provisioning) 

• Allowance of customer access to OAM&P services 

• Seamless integration of services 

• Network and element management . 

DPE Architecture 

Fig. 2 shows the components and services that make up the 
DPE architecture. 

DPE Kernel. The DPE kernel provides the foundation for 
building block interaction and execution services. To imple- 
ment these services, the DPE kernel uses the services pro- 
vided by the underlying native computing and communica- 
tions environment, which include: 

• IK'E: threads, security, RPC, and IDL compiler 

• CORBA: HP ORB+ with IIO and DCE CIO protocols and 
C-IDL compiler 



• IIP OpenVievv components XMP API, pmd (postmaster dae- 
mon), orsd (object registration service), and ovead daemon 
(event sieve agent). 

The DPE kernel is resident in every node of a distributed 
system. Building blocks and other DPE components at a 
node cannot access the DPE kernel at other nodes directly. 
Access to the DPE kernel services at a remote node is ac- 
complished using the interprocess communication facilities 
of the native computing environment of the node. 

Contract Adapter. A contract adapter is an application pro- 
gramming interface that provides all the transparencies re- 
quired by a client or server building block. It also provides 
an API for accessing either application-level services or ser- 
vices provided by DPE. Contract adapters are kept as library 
modules which can be linked with building blocks before or 
during execution. 

The inclusion of adapters as components of DPE implies 
I hat the components of DPE increase over time as new ap- 
plications are deployed in a network. When a contract type 
is specified and registered for some application-level service, 
adapters for these contract types can be automatically gen- 
erated and made a part of DPE. 

DPE Services. Each DPE service is a building block and 
access to its functions is only through Contracts offered by 
the DPE service. A node may have zero or more DPE ser- 
vices installed. Since access to a function provided by a DPE 
service is available only through a contract, a building block 
or a DPE service in a node can use the functions provided by 
a DPE service in a remote node. Thus, DPE services depend 
on the communication and execution services provided by 
the DPE kernel. References to contracts of some of the DPE 
services, such as the trader, can be passed to a building 
block when it is activated. 

Although both DPE services and applications are built using 
the concepts of building blocks and contracts, there is a fun- 
damental difference between the two. DPE services do not 
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provide network resource management functions, nor do 
they provide telecommunications services to network cus- 
tomers. These functions are provided only by applications. 

Fig. 3 shows the interactions among the DPE services shown 
in Fig. 2. An arrow directed from one service to another 
indicates that the source service provides services to the 
destination service. 

Contract Trader. This DPE service provides a discovery service 
for client and server building blocks. It is the key service for 
providing location transparency in a distributed network. 
When a building block offers a contract, information about 
this contract is conveyed to the DPE kernel. This informa- 
tion includes tin- name of the corresponding contract type 
and the value of the service attributes pr ovided hy the 
contract. DPE stores tliis information in the repository. 

When a client wishes to invoke an operation defined in a 
specified contract type, it queries the DPE trader for one or 
more references to contracts that match the specified type 
and whose service attribute values satisfy a c onstraint 
expression supplied hy the client. Regardless of where the 
server is physically located, the client can discover servers 
at run time, based on (he latest contrac t Information re- 
corded in the repository database: The DPE trader provides 
two types Of contract trading: attribute-based trading and 
resource-based trading. 

The attribute-based form of contract disc overy is based on 
the specified contract type and a constraint expression in- 
volving any number of the sen ice attributes. The constraint 
expression used by HP DPE is modeled after the ANSAware 
2.0 constraint language. This language supports relational 
operators on attributes and maximum, minimum, and logical 
operators. This provides a great deal Of flexibility in how a 
client discovers a server. 

An example of a constraint expression might he a request to 
find one or more print servers that can print in color, provide 
A4 size paper, and use PostScript"- 1 fonts. The constraint 
language would express this request as: attribute. list = color, A4. 
postscript. If we need a certain capacity and speed tor the 



Building Blacks 




printer, we might add a request for faster tlian six pages per 
minute: attribute Jist > 6. 

A resource-based form of contract discovery is an extension 
of attribute-based trading and is used by resource manage- 
ment applications. In resource management applications, it 
is typical to provide service over a domain of resources. 'litis 
domain may be dynamic. An example would be- a c onnection 
management application that is responsible for providing 
connection management services to all clients whose phone 
numbers ( domain ) begin with area code 408 and have the 
exchange number 4-17. This application may offer contracts 
over a domain that may vary in size depending on how mam 
phone numbers are actually assigned (e.g.. all the munbers 
following 447). This type of trading requires the client to 
supply a contract type name, a constraint expression, and 
the name of the resource. With this information the HP DPE 
trader can loc ate a server offering a contract of the appro 
priate type thai satisfies not only the search constraint ex- 
pression, but also the specified resources. 

Repository Server. This I >PE service maintains persistent in- 
formation for the operation of DPE It stores specifications 
of trading attributes, contracts, building blocks, and configu- 
ration information. The repository server provides operations 
for the creation, retrieval, update, and withdrawal of DPE- 
persistent objects. These reference objects are used to initial- 
ize, activate, deactivate, and withdraw contract and building 
block instances using a generic front-end administrative 
tool. This server is implemented Using the ObjcctStore 4.0 
OODBMS from Object Design Inc. 

The information stored in the repository can be used for 
several purposes. The DPE front end can traverse repository 
information to help application developers locate potential 
reusable attribute types, contract types, and building-block 
type specifications. It also provides type information that 
allows the DPE controller to check for valid operation 
parameter types at run lime. The following three kinds of 
information are stored in the repository, 
Specification information. This consists of information con- 
tained in contract type specification templates and building- 
block type specification templates registered with the DPE 
repository. 

Configuration information. This consists Off information con- 
tained in the building-block configuration templates, contract 
configuration templates, and node configuration templates 
registered with the DPE rej>ository. This means that the re- 
pository contains informal ion needed for managing building- 
block instantiating operations or stall up operations 
Trading information. This consists of informal ion thai sup- 
ports trading operations, specifically contract types ;uul 
contract instances. 

Registrar. This DPE service prov ides registration and with- 
drawal services for the various templates used in the oper- 
abilily services, including specification templates, installation 

templates, and configuration templates, its function is to 
parse and verify the correctness of the specification tem- 
plates before invoking the registration operation of the 
repository server. 



Fig. 8. Interrelationships between different componenta In the l IPE 
services. 
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Fig. 4. The DPE graphical user interface. 

Node Controller. The node controller at each node provides 
activation, deactivation, monitor, and restart functions for 
building blocks configured in that node. It receives notifica- 
tions when a building block is started and deactivated, and 
continuously monitors the "liveness" of all building blocks 
executing in the node. Since the implementation of these 
functions is dependent on the native computing environ- 
ment's facilities, one instance of the node controller building 
block is required in each node. 

Management Front End. HP DPE provides a graphical front 
end and a command line interface to DPE system adminis- 
tration, building- block management, repository browser 
func tionality, and DPE shutdown and restart functions. This 
user interface offers a generic and uniform way of managing 
the whole DPE domain from any node. DPE objects present 
in the GUI are organized in a hierarchical structure similar to 
the renowned Smalltalk browser. This structure is organized 
as nodes, building block types and instances, and contract 
types and instances (see Fig. 4). The DPE front-end inter- 
face provides the following functions: 
Contract building-block type registration 
Activation, shutdown, and withdrawal of building-block 
instances 

Activation, shutdown, and withdrawal of contract instances 
Setup and modification of contract trading attributes 
Browser for DPE objects. 

With the command line interface, routine DPE administra- 
tive tasks can be automated using shell script languages. 



DPE Telecommunications Examples 

This section provides two examples of the use of HP DPE in 
the design and deployment of telecommunications services 
and applications. The steps illustrated in these examples 
present a high-level view of the communications that occur. 
The ac tual designs are much more complex. Also, to reduce 
the complexity of the figures, three assumptions have been 
made: 

• All interfaces that are used have already been registered 
with the DPE registrar, and binding information for each 
interface is available from the DPE repository. 

• All communication with the DPE trading service is done via 
an RPC mechanism. 

• Most applications will either trade at initialization time to 
obtain binding handles or simply use a well-known address 
to maximize throughput . Trading during execution will most 
likely be reserved for those occasions that dictate the need 
for dynamic binding. For illustrative purposes, however, the 
examples show trading occurring for each initial communi- 
cation between any two modules. 

Example 1: Permanent Virtual Circuit Service 

The most basic connection service provided by broadband 
networks is a permanent virtual circuit (PVC) service. This 
service provides the capability of setting up a connection 
between two or more points with given bandwidth and 
quality-of-service (QoS) parameters. Typically PVCs are 
long-term connections used to interconnect LANs or provide 
long-term video service between distant points. Fig. 5 illus- 
trates how a simple PVC service might be designed using 
an architecture based on INA. Each of the following steps 
corresponds to a number in Fig. 5. 

1. The PVC presentation module consults with the DPE trad- 
ing service for the location of the PVC processing module 
applications. This communication is done via an RPC 
(remote procedure call) interface. 

2. The PVC presentation module provides the PVC processing 
module with the user input parameters that define the PVC 
being requested. This communication is done via an RPC 
interface. 

3. The PVC processing module consults with the DPE trader 
to locate the connection management application server 
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switched virtual circuit service. 



thai controls the switch servicing the originating end of the 
PVC. This is done via an RPC interface. 

4. The PVC processing module uses the DPE RPC mechanism 
to access the connection management application. If the 
connection requires more than one switch, the connection 
manager will trade for and bind to another connection man- 
ager to move the connection towards the termination point 
(tliis is not shown in Fig. 5). 

5. The connection manager trades for the bintiing handle of 
the managed object agent that services the originating (and 
terminating if local I points. For performance reasons, in 
most designs this step is done at system initialization time. 

6. The connection manager instructs the managed object 
agent to connect the originating end using the DPE system 
management protocol CMISE (Common Management Infor- 
mation Service Element). 

7. The connection manager instructs the managed object 
agent to connect the terminating point using the CMISE 
protocol. 

S. The connection manager uses UPC to request a binding 
handle from the connection data building block. 

9. The connection manager requests the connection data 
building block to update its data store to reflect the addition 
of the new PVC connection. The communication is done via 
RPC. 

10. The connection manager reports the establishment of a 
connection back to the PVC processing module via an RPC. 

1 1. The PVC processing module returns the status of the 
connection establishment back to the PVC presentat ion 
module for display to the user. 



Example 2: Switched Virtual Circuit Service 

This example shows that the modularity and code reuse 
capability of the DPE architecture can be used to add new- 
features. The switched virtual circuit implementation shown 
in Fig. 6 provides users with the capability to establish or 
reconfigure existing connection sessions at any time, much 
like voice telephony service. As shown in Fig. 6 the connec- 
tion management, data building block, and managed object 
agents are all being reused. Only the top two modules need 
to be replaced with new code. 

Summary 

This paper has presented an overview of the HP DPE imple- 
mentation. DPE plays a key role within the Telecommunica- 
tions Information Networking Architecture (TINA). HP DPE 
offers a development environment to develop distribution 
transparency for both RPC-based and CMIP-based INA-com- 
plianl applications. This paper has also detailed the services 
provided by HP DPE and described the implementation of 
the contract trading servers and contract adapters, the key 
components providing distribution transparency. 
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HP OEMF: Alarm Management in 
Telecommunications Networks 



This article explains the HP OpenView Element Management Framework 
concept, which is based on the HP OpenView Fault Management Platform 
(FMP) and complements the functionality of the FMP to provide an 
integrated network management solution. This article also explains the 
FMP, which facilitates efficient management of alarms in a 
telecommunications network, and the open APIs provided in the FMP, 
which allow seamless integration with other applications. 

by Sujai Hajela 



There has been an unprecedented growth in the telecommu- 
nications industry around the globe. The rapid evolution of 
new technologies, the offering of a broad spectrum of data 
services, and the need to have fast access to Information are 
some of the factors that have contributed to a tremendous 
increase in the number of subscribers to telecom services. 
This has imposed great demands on the telecommunications 
networks of both public and private operators. To keep up 
with the demand, telecom operators are expanding their 
existing infrastructure at a hectic pace. Furthermore, deregu- 
lation of the telecommunications industry has led to the 
emergence of a number of private service providers, and this 
has created keen competition within the industry. A good 
quality of service at an economical price has become a key 
factor for service providers to increase their customer 
bases. 

Telecommunications Management Network 

Offering a high quality of telecom services and at the same 
time generating high revenues requires efficient management 
of I eleconummications networks by the service providers. 
The Telecommunications Management Network (TMN) 
defines activities that aid in managing a telecommunications 
network. According to ITU-T Recommendation M.3010, a 
TMN is intended to support a wide variety of management 
areas including planning, installation, operations, adminis- 
tration, maintenance, and provisioning of telecommunica- 
tions networks and services. The following five functional 
areas have been identified in TMN (ITU-T Recommendation 
M.3400): 

Fault management 
Configura! ion management 
Performance management 
Security management 
Accounting management. 

Fig. 1 shows the TMN functional blocks and components. 
The TMN architecture coasists of the functional architecture, 
the information architecture, and the physical architecture. 
The TMN functional architecture defines the following 
blocks: 

Operations systems function (OSF) 



• Mediation function (MDF) 

• Network element function (NEF) 

• Workstation function (WSF) 

• Q adapter function (QAF). 

The TMN information architect tire defines the information 
exchanged between these functional blocks. 



Operations 
System | Workstation 

OSF *^^El 




Fig. 1. Telecommunications Management Network (TMN) runctional 
blocks and components. (I" = function, e.g., OSF = operations system 
function.) 
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The TMN physical architecture provides a means to trans- 
port and process information. The physical architecture is 
made up of the following types of physical components: 
Operations system (OS). Performs OSF. 
Mediation device (MD). Performs MDF. 
Q adapter (QA). Performs QAF. that Is. connects network- 
elements and operations systems with noncompatible inter- 
faces to OSI Qx and Q3 interfaces. 

Data communications network (DCS"). Performs data com- 
munications function (DCF). which is used by the TMN 
functional blocks to exchange information. 
Network element (N'E). Performs NEF. 
Workstation (WS). Performs WSF. 

OpenVlew Element Management Framework 

The IIP OpenView Element Management Framework (OEMF) 
aims to provide a set of management activities defined in 
ITT-T Recommendation M.3400 to facilitate efficient man- 
agement of a telecommunications network. The functional 
areas covered within the OEMF are fault management 
(Including trouble management), performance management, 
and other third-party applications to complement the existing 
set of applications under the OEMF umbrella — for example, 
configuration management and asset management. 

OEMF is an open system that makes possible I he detection, 
isolation, and correction of abnormal operation of the tele- 
communications network. OEMF consists of the HP Open- 
View Fault Management Platform (FMP) integrated with the 
Trouble Ticketing System provided by Remedy and the Per- 
formance Management System from Metrica. Other third- 
party applications for inventory, asset, and configuration 
management have also been integrated Integration with 



test and measurement products like HP AcceSST further 
enhances the OEMF functionality. 

Fig. 2 illustrates tlie physical architecture of the OEMF. 
OEMF has a distributed architecture in which different man- 
agement activities can reside on different servers or on the 
same server. OEMF offers application availability, that is. if 
one of the management activities ceases to function, the 
operator can still execute the functionality provided by the 
other applications. 

In the TMN hierarchy. OEMF resides between the network 
management level and the element management level ( Fig. 3), 
It can manage the network elements directly or can be inter- 
faced to an existing element manager to manage the network. 
Providing this flexibility to OEMF are a rich mediation ser- 
vice and APIs (application programming interfaces) for inte- 
grating with customer-specific data collection mechanisms. 

Fault Management Platform 

The FMP is a fault management platform that provides util- 
ity tools for managing alarms front multivendor devices and 
network element managers. It is based on the IIP OpenView 
Distributed Management Platform. It has an extremely open 
architecture, which facilitates a seamless integration of 
third-party applications, as manifested by the OpenView 
Element Management Framework described earlier. Fig. 4 
illustrates the FMP functional blocks. The main components 
of the FMP are the mediation device block, the FMP server 
block, and the graphical operator interface. 




FiR. 2. Physical srchitectufe of the 
I IP OpenView Element Manage- 
ment Framework (OEMF). I'MI' is 
the I II' OpenView Fault Manage 
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Fig. 3. In Ilic TMN hierarchy, the HP OEMF resides between the 

network management level and the element management level. 

The mediation device block provides the mediation and Q 
adapter functions and (he FMP server provides the opera- 
tions systems function. The mediation device logs, formats, 
tillers, maps, and finally correlates all alarms it receives 
from network elements into ITU-T X.733 alarm reporting 
format and sends these alarms to the FMP server for alarm 
management. The mediation device can send the alarms to 
the FMP server using the C'MJSE protocol over the CM1P 
stack provided by the HP OpenView Distributed Management 
Platform, or optionally, using the CMIP-LITE protocol (an 
FMP representation of the X.733 alarm report) over TCP/IP. 

The FMP server performs the problem condition manage- 
ment services. It provides graphical operator interfaces to 
aid in the management of the alarms being received from 
the network elements (which are performing ihe network 



element function ). These graphical interfaces provide Ihe 
means to Interpret TMN information for the managemenl 
information user. They perform the workstation function. 

The FMP provides the fault management activities in a tele- 
conimiiniealions network. However, lo manage a telecom- 
munications network, other managemenl activities such as 
(rouble management, performance managemenl. and eonfig- 
uralion management are also required. This requirement 
contributed to Ihe OEMF concept, which allows a broad 
spectrum of best-in-<iass applications, regardless of manu- 
facturer, to be integrated With FMP to provide an integrated 
network managemenl solulion. This integration is made 
possible by a range of open APIs provided in the FMP. The 
HP OpenView Distributed Managemenl Platform APIs fur- 
ther enhance the integration capabilities. 

Mediation Device Block 

The mediation device logs raw alarms, formats and niters 
alarms from events, correlates these alarms, and then for- 
wards them to the FMP server in the X.733 alarm reporting 
format. The mediation function is extremely imporianl as 
the FMP server receives and manages alarms in a heleroge- 
neous, multivendor, mullineiwork environment in which Ihe 
network elements send events in varying formats. Fig. 5 
illustrates Ihe functional blocks wiihin Ihe mediation device. 

The mediation device provides a set of data collectors, 
which collect data over RS-232, TCP/IP, and SNMP. Reports 
in X.733 format can be senl directly lo the FMP server using 
CMIP protocol. For data colleciion over X.25 and other 
types of networks, customer-specific data collectors can be 
written using mediation device connection APIs. These data 
collectors forward the events to the event logging module, 
which logs them into raw log files. The event logging module 
forwards the valid events lo the event formatting module, 
which parses the incoming events and then classifies and 
formats (hem into message classes based on the parsing 
rules defined in the configuration. These formatted events 
are then logged into message class files corresponding to 
the message classes. The event formatting module forwards 
the events to the event mapping module, which fillers the 
alarms from events, converts Ihe alarms into the X.733 
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Fig. 5. Mediation device functional block diagram. 

alarm report format and forwards them to the event filtering 
and correlation module. The correlation module correlates 
repealed alarms, transient alarms, and related alarms for a 
network element. The FMP supports a two-stage correlation 
approach in which the correlation functionality Is provided 
al the mediation device and at the FMP server. The correla- 
lion module forwards the alarm to the module interfacing to 
the FMP server. This module encodes the alarm into CMIP 
and sends it over the CMIP stack provided by the HP Open- 
View Distributed Management Platform or optionally (de- 
pending upon the configuration) encodes the alarm into 
CMIP-LITE and sends it over TCP/IP to the FMP server. 

Correlation in the FMP 

The FMP allows t wo stages of event correlation: one at the 
mediation device level and the other at the FMP server level. 
The correlation at the FMP server is clone across the network 
being managed because the server has access to the topology 
database. The correlation at the mediation devic e is restricted 
to the net work elements to which the mediation device is 
connected. The correlation al the mediation device level is 
clone primarily to prevent not -so-important data from being 
forwarded from the mediation device to the FMP server. 



The FMP has two types of correlation: repeated/transient 
correlation and root-cause/related correlation. Repeated/ 
transient correlation correlates alarms that are identical 
( they ntay have different severities) and are being emitted 
continuously by a network element. Root -cause/related cor- 
relation correlates alarms that have occurred because of a 
root-cause alarm and are not as important to the operator. 

Let's take an example of root-cause/related correlation in a 
GSM network. Assumptions: 

• MSC-1 is connected to BSC-1 which is connected to BTS-1 
through BTS-4. 

• An alarm A:MSC-1 ( that is, an alarm of type A:MSC at MSC-1) 
causes an alarm B:BSC-1 (an alarm of type B:BSC at BSC-1). 

• The alarm B:BSC-1 causes an alarm C:BSC-1. 

. The alarm C:BSC-1 causes alarms D:BTS-1, D:BTS-2, D:BTS-3, and 
D:BTS-4. 

• Of all these alarms, only A:MSC-1 is significant. 

Fig. fi illustrates the scenario. Based on the above assump- 
tions, if an alarm A:MSC-1 occurs, the operator will also 
receive the alarm B:BSC-1 which will further cause alarms 
C:BSC-1 and D:BTS-1 through D:BTS-4. Even though the real 
problem is with MSC-1, the operator receives numerous 
alarms, many of which are of no signific ance. 
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Fin. 6. Scenario of alarm generation to an example QSM ribwort 

Without correlation. Many extraneous alarms can be generated in 

addition in Hje root-cause alarm, 

Let's specify the correlation rules to be as follows (the 
formal of ihe event correlation rules specification has been 
simplified lo explain Ihe concept): 



Rule 1: ROOTCAOSE 
Rule 2: ROOTCAUSE 
Rule 3 : ROOTCAUSE 



A :MSC RELATED 
B:BSC RELATED 
C-.BSC RELATED 



B:BSC 
C:BSC 
D: BTS 



Correlation window: 20 seconds 



With these correlation rules in effect, the operator will re- 
ceive only the alarm A:MSC-1, which is Ihe Significant alarm. 
This behavior is illustrated below: 

( orrelatioii window (total elapsed time) = 20 seconds 



Arrival of A:MSC-I ->I->A:MSC-1 sent 
Arrival of B:BSC-1 >l 



(correlated by rule 1 ) 
Arrival of C:BSC-1 >l 

(correlated by rule 2) 
Arrival of D:BTS-1 



->l 



(all BTS correlated by rule 3) 
Arrival orD:BTS-4 >l 

End of Correlation Window 



All alarms matching the correlation rules and occurring 
Within the correlation window are subject to correlation. 
The correlation window can be a fixed or a sliding window. 
The arrival order of alarms is not important — in the above 
example, the alarms could have arrived in any order. As long 
as they arrive within the correlation tune window, they get 
correlated. If a related alarm arrives before a root -cause 
alarm, it is held in the correlation module until the end of 
Ihe correlation window. If the root -cause alarm does not 
arrive within Ihe lime window, the related alarm is sent out 
as uncorrelated. If Ihe root-cause alarm arrives before the 
related alarms, it is sent out immediately. In the scenario 
above. Ihe A:MSC-1 is sent out by the correlation module 
immediately and is not held back until the end of the cor- 
relation window. 

Event correlation services are available in HP Open View 
Distributed Management Platform 4.21 as an option (see 
article on page 31 ). Event correlation services fun her 



complement the event correlation provided by the FMPand. 
when integral i'd with the FMP, greatly enhance Ihe correla- 
tion functionality of ihe fmp 

FMP Server Block 

The F'MP server provides problem management services. It 
logs, correlates, and distributes the alarms to the graphical 
operator interfaces. Fig. 7 shows Ihe functional blocks within 
the FMP server. 

An alarm is received from the mediation device (there may 
be one or more mediation devices) either in CMIP or CMIP- 
LITE by an interfacing module, which decodes and forwards 
it to the alarm logging module. The alarm logging module 
logs the alarm in the alarm database. This alarm is (hen 
passed to the alarm correlator module for correlation. This 
is the second stage of correlation, the first being at the medi- 
ation device. Correlation at the FMP server is performed 
across the network because the server has access to the 
topology information stored in the topology dalabase, which 
resides at Ihe server. After Correlation, the alarm is distrib- 
uted to the alarm handling module and the network stains 
monitor module. The alarm handling module manages prob- 
lems. Every alarm need not be a new problem — many alarms 
may be sent for Ihe same problem. The alarm handling mod- 
ule identifies the alarm as belonging to a problem if it origi- 
nates from the same net work element and has the same 
probable cause and Specific problem fields as the problem 
(these fields are specified by ITU-T X.733). The alarm han- 
dling module checks whether a problem condition already 
exists for the alarm received. If it does, then an update to 
the problem is sent to all Ihe connected alarm viewers. 
Otherwise, a new problem condit ion is created and sent to 
the aJatm viewers depending upon Ihe span of control de- 
lined for each alarm viewer. 

The network status monitor is responsible for status propa- 
gation according to the configuration rules. Depending upon 
Ihe severity of the alarm, Ihe network status monitor calcu- 
lates and sets the status of t he alarming network element on 
the network map. The network stains monitor calculates the 
status of objects based upon the severity of objects both on 
the map and not represented on the map (norvmap objects), 
The need to support the concept of nonmap objects arises 
because in a telecommunications environment, ihe number 
of objects being managed can be very large. Also, the opera- 
tor may prefer not to see all of the objects being managed 
on the map, but would want the status of the nonmap ob- 
jects to be considered while calculating the stains of I he 
higher-level objects (in the containment hierarchy) that are 
represented on the map. 

The status manager server (or simply status manager) facili- 
tates the submission of outage schedules and maintains in- 
formation regarding the outage of the network elements. 
Operators submit the outage information through the status 
manager clients. 

Graphical Operator interfaces 

The FMP includes a set of utility tools thai provide a graphi- 
cal interface for the operator to manage the telecommunica- 
tions network. The tools provided are the alarm viewer. Ihe 
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Fig. 7. KMi' server functional block diagram. 



network map application, and the status manager clients for 
submitting outage schedules. 

Alarm Viewer. The alarm viewer is an Xll/Motif-based appli- 
cation that allows the operator to view the faults occurring 
in the network being managed and provides facilities to take 
corrective actions to handle these faults. Fig. 8 shows the 
alarm viewer window. 

The alarm viewer receives the problem condition from the 

alarm handling module. It allows the operator to select and 

perform the following actions on the selected problem 

condition: 

( Kvn 

Disown 

Discharge 

Locate 

View Problem Condition History 
Create Trouble Ticket 
View Details 
Print. 

By owning a problem condition, the operator acknowledges 
the presence of a fault. The operator can then locate the 
alarming network element on the network map and create a 



trouble tic ket for the problem Once the problem has been 
rectified, it can be discharged. On being discharged, the 
problem disappears from the alarm viewer. An audit trail is 
maintained in the alarm database regarding the actions per- 
formed on the problem. A list of all the alarms corresponding 
to the selected problem condition Ls displayed by clicking 
the Problem Condition History button. The alarm viewer can be 
configured to display only the fields in which the operator is 
interested. The Details button can be clicked to view the de- 
tails of the problem condition. A hard copy of the selected 
problem condition can be obtained by selecting the print 
option. 

The alarm viewer provides visual aids for quick identification 
of the severity of the problem. The columns in the problem 
condition row are color-coded and signify the outage, the 
severity, and the ownership status of the problem. 

An operator can invoke an alarm viewer and perform actions 
on the selected problem conditions. However, operators 
need to be registered with the FMP server, and their spans 
of control, or management dumuins, need to be defined. 
Their control can be defined on the basis of the network 
instance, the network element class, and the network 
element instance. The alarm handler ensures that all the 
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Fig. 8. Alarm viewer window. 



alarm viewers are consistent in case there is overlap in the 
operators' spans of control (it is common to have multiple 
operators responsible for the same network elements). For 
example, if a problem condition is owned at one alarm 
viewer, this owned status is propagated to other alarm 
viewers displaying this problem. 

Alarm viewer menu options allow an operator to customize 
the alarm viewer. Operators can set their own soiling crite- 
ria for problem condition display. They can also set then: 
own view preferences, for example to view problems from a 
certain network, view problems of a certain severity, view 
problems they own, and so on. These menu options offer 
flexibility and convenience to help the operators efficiently 
manage Ihe problems occurring in the network. 

The alarm viewer allows external and customer-specific 
applications to be registered with it. A problem condition 
can be selected and any of the registered applications can 
be invoked for the selected problem condition. This is an 
extremely useful feature which allows integration of the 
FMI' with best-in-class applications from any vendor to com- 
plement the FMI' functionality. 

Network Map. The network map is an Open View Windows 
application that displays the network being managed and 
the status of the network elements within it. The network 
elements are represented by icons and the colors of the 
icons represent their severity. The network map gets status 
updates from Ihe network status monitor module. It allows 
the operators to navigate through the managed network and 
isolate the network elements generating the problem condi- 
tions. It also allows updating of the topology either interac- 
tively through the menu options provided or programat ically 
through the map loader APIs. The network map can be cus- 
tomized by creating logical views of the network. Thus, an 
operator can nav igate through the whole network hierarchy 
while a manager can choose to look only at the status of the 
network at a higher level without going into the details of 
the network elements within the network. 

The network map has the FMP registered as an application. 
The FMP menu option allows Ihe operators to invoke various 
ap pl i c ati o ns like the alarm viewer and the status manager 
clients. 

Fig. 9 shows a network submap for an example GSM net- 
work. 



Status Manager Client. The sialus manager client is an XI 1/ 
Motif application thai allows an operator to submit outage 
schedules, that is, an operator can submit a proposal to put 
a network element out of service or restore a net work cle- 
ment back into service. The operator needs lo be configured 
for the status management capability to submit the outage 
schedules. The operator can specify the start and end times 
of the outages and whether the network element will be 
restored manually or automatically to in-service status. If an 
alarm is generated by a nelwork element that is in the outage 
stale, it is flagged by a different color in the first column of 
(he alarm viewer. The FMP server can also be configured 
such thai alattns from network elements in outage status are 
not sent lo Ihe alarm viewers at all. Information regarding 
the outage status of Ihe network elements is maintained by 
the status manager server. 

FMP Configuration 

The mediation device has to be configured to be able to re- 
ceive, format, and map events received from multivendor 
network elements in the X.733 alarm format The object 
model of Ihe network being managed, (he different types of 
network elements, event correlation rules, operators' spans 
of control, and status propagation rules all have lo be con- 
figured. Informal ion regarding the mediation devices con- 
nected to the FMP server (the FMP server can be connected 
lo more than one mediation device) and any customer- 
specific data collectors conned ed to the mediation devices 
also needs lo be supplied. 

FMP provides a screen-based GUI utility — the configurator 
— CO aid in configuring the FMP and customizing il lo manage 
a heterogeneous telecommunications network 

FMP Application Programming Interfaces 

Throughout the design of the FMP, an Open architecture and 
ease of integration were always given maximum importance. 
The FMP allows seamless integration will) other applications 
as a result of its rich set of C and C++ APIs. The various APIs 
are described in the following paragraphs. 

Data-Collector-to-Mediation-Device Connection APIs. These 
APIs can be used to write customer-specific data collectors 
to send events received from the network elements to the 
mediation device. Apart from data collection, these dala 
collectors can also use these APIs (o inform the mediation 
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Fig. 9. Network Mibmsp (bi .1 re- 
gion in an example GSM network. 



device regarding their operational status and to gel info*m8? 
lion regarding the operational status of the mediation device. 

High-Level Parsing APIs. High-level parsing APIs facilitate the 
validation or events received from the network elements. 
The data collectors can use these APIs lo find the validity of 
art incoming event and Hag the event as valid or invalid. This 
information is used hy the event logging module in the medi- 
ation device 10 lag the event as valid or invalid in the raw log. 

Pseudocode for a sample data Collector Using the data foi- 
led or and high-level parsing APIs is as follows: 

main( ) 
f 

Open the network element port 
for ( ; ; ) 



( 



If (Data received from network element 
port) 

i 

//High-level parse the input data 
/ /received 

FaultBuf = HLPParse(Data Received) 
//Send the structure returned by the 
//HLPParse to the mediation device 
DCSendFaultToMDI FaultBuf ) 

) 

//Inform the mediation device if the 
//network element port is not OK 
If (Error in network element port) 

DCSendPortStatusToMDI Port is not OK) 



//If the mediation device is shutting 
//down, shut down this data collector 
If ( ( (msg = DCReceiveFromMD( control 

message from MD ) ) == MM_ SHUTDOWN ) 
ShutdownThisDCI ) ; 



) 



Log APIs. The medial ion device logs raw dala received from 
the network elements. It then Classifies these events into 
message classes and logs them in the corresponding message 
class file. The log APIs can be used 10 access these files. A 
number of applications can use the mediation services of 
the FMP and have the data collected al the mediation device 
in a formal desired hy Ihein. These applications can then 
access this formatted information using the log APIs. Many 
interesting and useful applications CM be written using the 
mediation and logging services provided by the FMP. An 
example is a raw log browser, which allows the operator 
to select an X.753 alarm from the alarm viewer and Ihen 
extract and browse the raw alarm data corresponding to the 
selected alarm. 

Application Registration APIs. These APIs allow the registration 
of external applications with the alarm viewer arid facilitate 
passing information aboul the selected problem conditions 
lo ItieSe applications. Application registration APIs can be 
used to integrate customer-specific applications. Once regis- 
lered, the applications can be invoked from the Applications 
menu opiion of the alarm viewer. Taking the example of the 
raw log browser. I he browser would first be registered with 
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the alarm viewer: Then a problem condition can be selected 
and I he raw log browser application can be invoked. Assum- 
ing thai a raw log index is passed as some field in the X.733 
alarm (e.g., rawlogmdex as a part of additional information), 
this application can use the APIs to extract this index, which 
can be used lo access the raw log. The trouble management 
system provided under the OEMF also uses these APIs. 
When a problem condition is selected and a (rouble ticket is 
created for il, the trouble ticketing application uses these 
APIs to get informal ion regarding the problem condition. 

Problem Condition Management APIs. These APIs allow an ap- 
plication lo interface to the problem condition management 
services. The alarm viewer uses these APIs. Customized 
alarm viewers, an automatic trouble ticketing application, 
;ui automatic problem condition discharge application, and 
other applications can be written using these APIs. Take, for 
example, an aiitomalic problem condition discharge applica- 
tion for managing problems for which the switch normally 
does not send a clear event. Based on certain criteria like 
the age of the problem condition, its sev erity, and so on. this 
application can be designed to discharge the problem condi- 
tion automatically without any manual intervention from the 
operator. 

Map Loader APIs. These APIs allow the customer's topology 
to be loaded into the FMP without having to add the objects 
manually into the FMP topology. This is extremely useful 



because the number of objects being managed can range 
anywhere from 4000 to more than 40,000. Map loader appli- 
cations can lie written to access the topology database of 
the customer and then populate the FMP topology using the 
map loader APIs. 

Conclusion 

The FMP APIs have led to the expansion of the number of 
products integrated under the OEMF umbrella. The FMP 
integrated with other best-in-class applications provides an 
enhanced telecom network management solution for effi- 
cient management of the multivendor, multi-equipment tele- 
communications networks of today. 
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HP OpenView Event Correlation 
Services 



When a fault occurs in a telecommunications system, it can cause an 
event storm of several hundred events per second for tens of seconds. HP 
OpenView Event Correlation Services (ECS) helps operators interpret such 
storms. It consists of an ECS Designer for the interactive development of 
correlation rules and an ECS engine for execution of these rules. 

by Kenneth R. Sheers 



Modem telecommunication Technologies such as SDH/SO- 
NET (Synchronous Digital Hierarchy/Synchronous Optical 
Network) and ATM (Asynchronous Transfer Model ran gen- 
erate large numbers of events when a fault occurs. Every 
logical and physical element involved in delivering a service 
that uses the failed or faulty element can generate multiple 
events. This can result in an event storm of several hundred 
events per second for tens of seconds. The task of telecom- 
munications operations staff is to determine the underlying 
cause from the thousands of events presented to them. 

HP OpenView Event Correlation Services (ECS) is designed 
CO deal with the problems associated with event storms in 
the telecommunications environment. The theory from which 
HP OpenView ECS technology has evolved was developed 
by HP Laboratories in Bristol, England. 1 ECS is delivered as 
two distinct components: the ECS engine and the ECS De- 
signer. 

The ECS engine is a run-time correlation engine. It executes 
a set of downloaded correlation rules that control the pro- 
cessing of event streams. At first release, the ECS correla- 
lion engine is integrated into the IIP < ipenVicw Distributed 
Management (DM) postmaster. 

The ECS Designer is a graphical user interface (GIT) devel- 
opment environment that allows the correlation rules to be 
developed interactively by selecting, connecting, and config- 
uring logical processing blocks. Once the rules have been 
created, their operation can be simulated and visualized using 
a log of events input to a correlation engine attached to the 
EC'S Designer, with the engine's concept of time controlled 
by the EC'S Designer. 

The correlation rules are created using a visual paradigm of 
nodes connected together to form a correlation circuit. 
Events logically enter nodes via input ports and leave via 
output ports. An output port of one node is connected to an 
input port of another node in the circuit, so that events flow 
through Che circuit from one node to the next. The functional 
node types provided with E( S are a superset of the basic 
types considered necessary and sufficient to perform real- 
linic event correlation. 

An event correlation circuit, Fig. 1, constitutes a set of cor- 
relation rules that can be compiled and downloaded to an 



Flow ol Events 




Fig. 1. Generic correlation circuit. Correlation rules are specified 
by such circuits. 



event correlation engine. It consists of a series of intercon- 
nected and appropriately configured nodes, together with 
any associated data anil relationship information. Fig. 2 
shows the ECS architecture and the relationship of the cor- 
relation circuit to the EC'S Designer and the ECS engine. 

Real-Time Engine 

A key differentiator of EC'S compared with other correlation 
systems is that it operates in real time while taking into 
account the real-world problem that events will often be 
delayed in the management network and delivered to the 
correlation system out of order. 

If events always arrived in bursts, it would be possible to 
buffer them on receipt and perform the correlation between 
bursts. However, event storms may be continuous, and the 
correlation engine should be capable of receiving the events, 
decoding them, and correlating them at the speed at which 
they arrive, continuously, without needing a mainframe to 
do the work. In EC'S, any buffering required for correlation 
of time-separated events is dynamic and completely inte- 
grated into the normal engine operation. 

In an ideal environment, a c orrelation engine is embedded 
into each piece of equipment that generates events. Corre- 
lated events from eac h piece of equipment are forwarded to 
another correlation engine where correlation across multiple 
systems is performed. This strategy reduces event volumes 
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Correlation Node Types 



Fifteen primitive node types are supplied with HP OpenView Event Cor- 
relation Services (ECS). Every correlation circuit must have one or more 
source nodes and one or more sink nodes. 

Source Nodes. This is where events enter a correlation circuit. There 
can be more than one source node in a circuit. For a top-level circuit, 
source nodes are connected to the engine's input ports, where events 
are delivered by the HP OpenView DM postmaster. 

Sink Nodes. This is where events leave a correlation circuit For a top- 
level circuit, the events are returned to the HP OpenView DM postmaster 
for delivery to management entities that have registered to receive them. 

It is necessary to be able to suppress unwanted events In the circuit 
paradigm, events are filtered by preventing them from flowing through 
different paths in the circuit. This is done by filter nodes and unless 
nodes. 

Filter Nodes. These suppress events based upon a configured expres- 
sion which typically uses the incoming event as an argument 

Unless Nodes. These forward an event unless another event was 
created within a configured (positive or negative) time period relative to 
the creation time of the first event, and the configured (filtering) expres- 
sion evaluates false. 

Events can be delayed in the management network, especially when the 
network is stressed. This may result in delayed events and events arriv- 
ing in a different order than the order in which they were created Delay 
nodes can be used when correlation decisions depend upon events being 
processed in the strict event creation time order 

Delay Nodes. These hold an event until the creation time is a config- 
ured number of seconds before the current time. This has the effect of 
guaranteeing that the events are output from this node in creation time 
order. 

Events may need to be stored for extended periods so that future correla- 
tion decisions can be made using the event history Subsequently, it may 
be necessary to extract complete copies of events from the storage. 

Table Nodes. These hold a logical copy of all events sent to the table, 
subject to configured retention parameters and conditions. Other nodes 
can examine the event list, stored in creation time order, and make pro- 
cessing decisions based upon the contents. 

Extract Nodes. These search a table node and extract a copy of one or 
more events from the stored list, subject to a configured condition. The 
search is triggered by an event arriving at the input port of the extract 



node, and the extracted events are output as a composite event Isee 
"Event Iypes" on page 36). 

While most of the useful information will come from the event stream, 
data may need to be obtained from outside the correlation engine. 

Annotate Nodes. These obtain data external to the engine and add it 
to an output composite event The external data is now available in the 
event for subsequent use in the downstream circuit. The annotate re- 
quest provides time for the request to be serviced, after which it will 
time out Other events continue to be processed during this period 

One of the fundamental features of ECS is the ability to collect and con- 
solidate discrete pieces of data from the event stream and from outside 
the engine to produce value-added information Events need to be ma- 
nipulated, including combining events into a single data unit, changing 
the structure of this unit, changing event data values, and creating new 
events. 

Combine Nodes. At these nodes, two or mure input event streams are 
combined into a single output stream, with each output event being a 
composite event containing an event from each input stream. Events on 
one stream can be held until events on other streams arrive. 

Rearrange Nodes. These change the structure of a composite event, 
including pulling a single normal event out of a composite 

Modify Nodes. These change attribute values of incoming events to any 
values required The values can be copied or calculated from any publicly 
available data. A copy of the original event is made, and the event copy 
is modified and output The original event is not modified. 

Create Nodes. These create a new event with a format controlled by a 
configured specification and attribute values set according to a config- 
ured specification. Event creation is triggered by an event arriving at the 
input port The event's attribute values can be set from any publicly avail- 
able data throughout the engine, including from the incoming event. 

Some basic utility functions are provided by the following nodes. 

Count Nodes. These count the events passing through the node. 

Clock Nodes. These generate an empty event every configured time 
interval This allows circuit logic to be triggered in the absence of any 
incoming events, enabling the absence of required events to be detected 

Rate Nodes. These calculate the rate at which events are passing 
through the node. 



All parameter values arc actually expressions that can use 
references to values stored in the do to Store and i<> relation- 
ships stored in the fori store (see "Fact Store and Data 
Store" on page 89). For example, where a value should be 
supplied for a parameter, the name of a variable defined in 
the data store can be used. The data store entries can be 
changed without changing the configuration of the node. 
Dynamic node parameters are evaluated whenever a new 
event arrives at the input port of the node. If these parameter 
expressions reference data store or fact store entries, updates 
to these stores will affect subsequent parameter evaluations. 
Tlus allows the behavior of a correlation circuit to be modi- 
fied dynamically. 



Like any primitive node, a compound node can have param- 
eters that must be set or configured when the node is instan- 
tiated. The parameters are defined and documented by the 
designer of the compound node. 

Ports 

All nodes have one or more ports, which are visible in the 
ECS Designer. Nodes are interconnected via ports appropri- 
ate to the required functionality. Depending upon type, nodes 
can have input ports, output ports, error ports, reset ports, 
and other types of ports. Normal operations occur through 
the normal input and output ports. For a filter node, the con- 
figured expression should evaluate true or false, causing the 
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Correlation Circuit 





Fig. 4. A compound node contains 
a correlation circuit that defines a 
new node type with user-defined 
functionality 



HP OpenView DM Postmaster 




Top-Level Compound Node 


Input Port -v^^ 


Source Sink 
r Node r- Node 

^- Invisible Connections -* 


Port Configuration: 

• Transit Delays 

• Event Types 






Output Port - 1 



(a) Top-Level Circuit Pon Connections 

Parent Correlation Circuit 

Compound Node 
Source 



Sink 



^Node ^Node 



Input Pon 



Invisible Connections 




Output Port 



lb) Compound Node Port Connections 



Fin. 5. Compound node port connections, (a) Top-lcvH 
(li) Lower-level. 



incoming event to be routed to the true output or the false 
output porl as appropriate. 

Where run-time errors occur in evaluating the expressions 
configured for particular node instances (not everything can 
be known before run time), an event will be output through 
an error output port. 

Except for the combine and compound nodes, primitive 
nodes have a fixed number of ports. The combine node can 
have up to 50 input ports (combining event streams). Trie 
compound node can have up to 50 input and output ports to 
support the encapsulated functionality. 

Reset Ports 

Delay, unless, combine, and annotate nodes can hold events 
in memory associated with an input pon pending some con- 
dition becoming true. Table nodes can hold events in long- 
term memory. 

When the engine is to be stopped or the correlation circuit is 
to be modified, tite future conditions can now never be true, 
and the applicability of stored events is indeterminate in the 
context of the modified circuit. Even if the circuit were to 
be stopped and restarted without change, the potential for 
pertinent events to have been missed invalidates the state of 
the correlation- Critical events that should have been output 
may now be discarded. 
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Count Node 

The count node (Fig. 1 ) is an example of a simple node. It has a single 
parameter, initial count, which sets the initial value of the count attribute. 
An event entering the increment input port increments the count attri- 
bute and is immediately output via the increment output port. An event 
entering the decrement input port decrements the count attribute and is 
immediately output via the decrement output port. An event entering the 
reset input port resets the count attribute to the initial count value and 
immediately exits via the reset output port At least an increment input 
port or a decrement input port must be configured or the compiler will 
generate an error. All output port connections are optional, and events 
routed to unconnected ports are discarded. The default value for initial 
count is zero. The count attribute is exported as a read-only attribute, 
which can be referenced in node parameters and expressions as <count- 
nodename>.count. If both the increment input and decrement input ports 
are connected, the count attribute will indicate the difference in the 
number of events entering these ports. 
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Fig. I, Count node. 
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It is necessary to be able to output the stored events before 
engine reset or reload so that potentially critical events are 
not lost. All nodes that store events have reset input and 
reset output ports. If an event is forwarded to a node's reset 
input port, any stored events will be output or discarded in a 
defined manner. The reset event will be output via the 
node's reset output port, possibly to a downstream node's 
reset input port, allowing a reset circuit to be added to an 
operational circuit. 

Public Data 

The nodes of a correlation circuit typically make decisions 
and perform actions based upon the arriving events, the 
information within the events, and the current time of the 
engine. Other data is also available to the dynamic node 
expression parameters to control node processing, including 
node attributes, the data and fact stores, and annotation data. 

Node Attributes. A node can export one or more data values 
for use by expression and condition parameters configured 



for other nodes throughout the circuit. The count node ex- 
ports a count attribute which increments or decrements for 
each arriving event. The table node exports two attributes: a 
COtmt at t ribut e whose value is I he number of events currently 
stored and a contents attribute whose value is a list of all 
events stored in the table. 

Compound nodes can export the attributes of any contained 
nodes as attributes of the compound node. If they are nol 
exported, the attributes of internal nodes are private to the 
compound node and will not be visible outside the compound 
node. 

Data and Fact Store. The data store contains entries of name- 
value pairs and the fact store contains entries of name- 
relation-name triples (see page 39 ). These stores operate as 
in-memory databases and are accessible globally throughout 
the correlation circuit. 

The data store entries allow values to be referenced by name, 
so that particular values need not be known when the circuit 
is designed. Using indirection through the data store also 
allows correlation circuits to be reused at multiple sites, with 
specialization via appropriate data store values. 

The fact store allows the relationships between objects to 
be tested by node parameter conditions and expressions. 
Typically the entries will be used to reflect network topology 
information, and will allow event, relationships to be deter- 
mined dynamically without building the network model 
information into the actual correlation circuit. 

Annotation. An annotate node (see page 40 J can be used to 
obtain data from outside the correlation engine for use 
within the engine. This data will be used to make correlation 
decisions, or to add to created events or modified events. 

Event Types 

Several event types can logically exist within a circuit. These 
include primitive events, composite events, and temporary 
events. 

Primitive Events. A primitive event is a single event as it 
entered the correlation engine, possibly with data values 
modified within the circuit, or an event created within the 
engine, suitable to be relumed to the external environment 
ECS currently supports CMIP (Common Management Infor- 
mation Protocol. ISO/IEC 9596-1) and SNMPvl (Simple Net- 
work Management Protocol, version 1) event types. The 
engine isolates the external event type from the internal 
functionality using specific decode and encode modules for 
each event type. This modular design allows additional 
event types to be supported in the future. Since the internal 
processing is not dependent upon the format of primitive 
events, it is possible to correlate events of any supported 
type with events of any other supported type. 

Composite Events. A coniposile event is an ECS internal 
mechanism that allows multiple events to be collected into 
a single addressable structure in which all members are ac- 
cessible (Fig. 6). The event aggregation capability is funda- 
mentally important for ECS. Collecting and processing mul- 
tiple events as a single event allows all important information 
to be collected together. Members of a composite event can 
be primitive, composite, or temporary events. A composite 
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Unless Node 



The unless node (Fig 1 ) is an example of a complex node The unless 
node will transmit an event arriving at the input port (the exciting event) 
to the output port, provided that no event arrives at the inhibitor input 
pon (the inhibiting event) which satisfies the criteria specified by the 
window parameter and the condition parameter These events can arrive 
at different times; either order is supported. The transit delays of arriving 
events must be within the window parameter limits to be accepted by 
the relevant port If an accepted inhibiting event arrives and there is an 
accepted exciting event in memory, the condition parameter is evaluated 
If an accepted inhibiting event arrives and there is no exciting event in 
memory, the inhibiting event will be held pending the arrival of an 
accepted exciting event, at which time the condition parameter will be 
evaluated. The condition parameter is a Boolean expression that can 
take both the exciting event and the inhibiting event as arguments. 
For example, 

condition: input event ( "device" ) 

= inhibitor_event ( "device" ) 

will evaluate true if both events were generated by the same device 
(assuming this information is contained in the events) Any environment 



data (data store, fact store, and node attributes! can also be used in the 
condition expression If the condition evaluates false, the exciting event 
is output via the output port If the condition evaluates true, the exciting 
event is inhibited and is output via the inhibited output port if one is 
connected, or discarded if not If the evaluation of the condition causes 
an error (e g , if a referenced event attribute does not exist), the exciting 
event will be combined with the inhibiting event and output via the error 
output port as a composite event If the error output port is not connected, 
the composite event will be logged. If the transit delay of the exciting 
event does not satisfy the window parameter transit delay window, the 
event is output via the fail output port If the inhibiting event fails this 
test, it is silently discarded The inhibiting event is never output except 
as a composite event as described above 

An event arriving at the reset input port causes any events held in the 
memory of the input (exciting) port to be output immediately via the fail 
output port, and any events held in the inhibitor input port memory to be 
silently discarded. The reset event is immediately output via the reset 
output port 
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Fig. 1. Unless node 



event is only denned within a correlation engine, and cannot 
be output from a lop-level circuil hack to the environment. 
Composite events can be passed into and out of compound 
nodes. 

Temporary Events. Where an evert is required as an internal 
container for dala, or where a trigger event is required, the 
engine will create a temporary event. For example, the clock 
node will emit a temporary even! at each clock period. There 
is no relevant data in this empty temporary event. It can be 
used in trigger correlation activity elsewhere in the circuit. 
Where results are returned in response lo a request by an 



annotate node, a temporary event is created to hold the data 
and returned lo the circuil as a component of a composite 
event. A temporary event can enter or leave a compound 
nolle, but it cannot be output from a lop-level circuil back 
to the environment. 

Enhancing Event Information 

A fundamental value proposition of ECS is that event infor- 
mation can be enhanced. What this means in reality is that 
all available information — for example, all information rele- 
vant to some network fault condition — is consolidated from 
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Table Node 



The table node (Fig. 1) is the only example of a special (and complex) 
node. The table node stores events for extended periods. The number of 
stored events is exported as the count attribute. All events stored in the 
table node are exported as a list of events in the contents attribute. The 
events in the contents attribute can be examined by expression and 
condition parameters of other nodes in the circuit, and extracted by the 
extract node. The table node stores a single list of events (the contents) 
in two logical areas. The current area is controlled by the save until and 
max events parameters, and the retained area is controlled by the retain 
condition and delete condition parameters. The two areas have different 
mechanisms for storage. The current area is based on physical and event 
age limits, while the retained area is based on evaluated conditions, 
which typically test data values within the events. 

The current area stores each event until the creation time of the event is 
more than save until seconds before the current time of the correlation 
engine, or until the number of events in the region exceeds max events 
Each event arriving at the input port is tested to see if the creation time 
of the event is less than save until seconds before the correlation engine's 
current time. If it is, the event is added to the current area (subject to 
the max events limit), and immediately output via the output port if con- 
nected, or discarded if the port is not connected. If the creation time of 
the event is more than save until seconds before the correlation engine's 
current time, the event is not added to the table, and is either output via 
the error output port if connected, or logged if the port is not connected. 

When an event is to be retired from the current area (based on age or 
volume), the condition specified in the retain condition parameter is eval- 
uated. This Is a Boolean expression that can take the retiring event as an 
argument and can access any environment data from throughout the 
circuit. If the expression evaluates true, the retiring event is logically 
moved to the retained area. If the condition evaluates false, the event is 
discarded. Events are retained in the retained area until they meet the 
condition specified in the delete condition parameter. The condition is 
tested for all events in the retained area whenever an event 
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Fig. 1. Table node. 

arrives, or at each correlation engine clock cycle. Any event for which the 
condition evaluates true is silently discarded. 

An event entering the reset input port causes all stored events to be 
silently discarded and the count attribute to be set to zero The reset 
event is immediately output via the reset output port. 
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multiple lime-separated events, the data store and fact store, 
and data external to the engine via annotation. 

When all pertinent informal inn lias heen assembled (and 
all superfluous data discarded), it must be forwarded to 
interested operations systems. This can be done by: 
Creating a new primitive event containing the consolidated 
information, using the create node to create Ihe event and 
copy the dala into the event. 

Modifying Ihe data values in an existing primitive event, 
using the modify node to change the values of the event's 
attributes before the event is output. 

The input primitive events, which each contain only a frac- 
lion of ihe total relevant information, can be suppressed. 
Only the new or modified events are forwarded to interested 
management entities. The residl is that the events actually 
delivered lo management systems contain enhanced infor- 
mation content. 

To aggregate all pertinent data into the delivered events, it is 
necessary to be able to collect the information together and 
process it through the engine as a single data unit. This 
allows correlation decisions to he applied to the logical block 
as a single unit, providing major efficiencies in Circuit design 
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Fact Store and Data Store 

The data store and fact store permit business, topology, and operating 
factors specific to a device or a set of circumstances in a managed net- 
work to be separated from the general correlation rules defined by the 
cotrelation circuit. The behavior of the correlation circuit can be changed 
by updating the data and fact stores as local conditions change without 
affecting the integrity of the correlation circuit This makes it possible to 
develop correlation circuits that are data-<iriven. promoting circuit reus- 
ability and reliability and design generality 

The data store contains a set of name-value pairs Any user-defined 
names can be used to identify the assigned values. In a circuit, the value 
can be referenced using the configured name. If the reference is by a 
static node parameter, the reference will be resolved at circuit load time 
For dynamic parameters, references are resolved every time an event 
triggers activity at the node. 

The fact store contains triples thingl-relation-thing2 A relationship can 
be any user-defined concept, such as is_contamed_in, is_the_parent_of. 
is_equal_to. is_gzumped_by. and so on The related things can also be 
anything the user requires in the circuit, such as switchl. rack17. cabi- 
netlO. circuitABC, and so on This means that a fact such as equipments 
is_contained_m rack27 can be defined In a circuit node, a condition 
parameter can test whether this relationship is true and take appropriate 
action if it is. 

The fact and data stores are loaded from files into memory. This model 
conforms with the notion that the run-time engine is designed for very 
high speed — faster than normal file I/O speeds The stores can be 
updated while the correlation engine is running, resulting in dynamic 
changes to the correlation rules 



and processing loads. Composite events are used to aggre- 
gate events into a single unit. 

Event Processing 

When an event is received by the correlation engine it must 
be decoded from I he specific format ( BER encoded*) suffi- 
ciently ,( > determine the event creation time and the event 
identification. These values are fundamenial to the operalion 
of ECS. The creation time must be known to allow the lime 
relationships between events to be known. The event identi- 
fication can be used explicitly to control which branch of 
the circuit the event will logically enter. 

HP Open View ECS has been designed for high performance. 
Event encoding and decoding, and event copying within the 
engine, are implemented using a just-in-iimc encode and 
decode mec hanism and sophisticated systems of header 
structure lists, event lists, pointers, and reference counts. 
An event is not fully decoded if not required by the correla- 
tion rule parameter expressions. References to events pass 
from node to node, rather than active events or copies of 
events. 

When an event Is forwarded down multiple paths in a circuit, 
reference counts are incremented. Only when one of these 
logical copies is modified (say with the modify node), is the 

BEP. stands fa Basic Encoding Rules HSO/IEC 8826. ITU T X 2091. The BER define how ASN.1 
(Abstract Synlai Notation 1 . ITU T X.20BI data rypes are encoded to be transported on the 
netwoik Both ot the primitive event types supported by HP OpenView ECS. that is. SNMP 
traps and CMIP notifications, ate encoded using BER 



event duplicated before modification. When the reference 
count is decremented to zero, possibly when the event is 
output from the circuit, the event is removed from the event 
list • 

Retained Events 

The transit delay of an event is defined as the number of 
seconds between the creation time of an event and the time 
that the correlation engine receives the event, assuming thai 
both clocks are synchronized. 

The example previously used considered the case in which 
an event A has arrived and a consequential event B is sup- 
pressed when it subsequently arrives. The correlation must 
consider the permissible transit delay range for event A to 
cover the situation in which event A arrives after event B. 
This requires that either event A or event B be retained in 
the circuit at the point where the condition is being tested. 
In a real-time engine, in which memory resources must be 
conserved, the ev ent should be retained only while there is a 
possibility that it may be required in an active correlation, 
and automatically destroyed when no longer required. 

A circuit must be configured with a transit delay window, 
which acts as an initial filter to eliminate any events with 
creation times outside this window relative to the correla- 
tion engine time. The circuit transit delay window is propa- 
gated into the circuit to calculate the transit delay limits on 
all nodes whose operalion depends on event time differ- 
ences. If a node imposes an additional time window for 
event comparisons (e.g.. an unless node allows an inhibiting 
event to occur at some time offset from the exciting event), 
the allowable transit delays for the subsequent circuit are 
automatically adjusted to include the additional possible 
transit delay. 

Events can be retained in port or node memory pending some 
condition becoming true. Each such event will be examined 
at each engine clock cycle to ensure that the Creation time 
relative to the engine time is within the computed transit 
delay window at thai point. Events failing to meet this re- 
quirement are released from memory automatically. 

Data Access and GDMO MIBs 

The tests and comparisons performed by the nodes must 
allow events to be tested for content. ECS prov ides high-level 
access to any element of an event, and has language data 
types dial map onto the ASN.l dala types in an event In ECS, 
each addressable component of an ev ent is referenced as a 
named attribute. For example, an event may be significant if 
ils severity attribute has a value of critical. ECS provides a 
sophisticated mechanism that allows the designer to specify 
this test (for a filler node) as: 

input_event ( "severity" ) = "critical" 

This Boolean expression extracts the severity attribute of the 
input event tests the value of the attribute, and evaluates as 
either true or false. 

The concept that an event lias a series of attributes that have 
values thai can be examined or modified is fundamenial to 
ECS. The attributes of an event are all Ihe components or 
elements of an event that are specified by the MIB (Manage- 
ment Information B;lscj thai defines ihe event. The MIB is 
added to the underlying IIP I ipenYiew DM platform so thai 
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Annotation 



The annotate node (Fig. 1) is special because it is the only node other 
than the source and sink nodes that interacts with the external environ- 
ment. It is necessary to create an external annotate server to service the 
annotation requests When an event arrives at an annotate node, it 
causes the engine to generate a CMIP event (an EcsAnnotateRequest 
notification) which is transmitted to the annotate server via the HP Open- 
View DM postmaster (pmd) and the XMP (X/Open* Management Proto- 
col) application programming interface. The server must have registered 
with HP OpenView DM to receive the annotate request event. Any data 
from the incoming event, or from elsewhere in the circuit, can be output 
with the request. This data is used to parameterize the request The 
annotate server must perform some user-implemented action or inquiry 
to obtain the information required by the request. The server will return 
the obtained data to the requesting annotate node with another CMIP 
event (an EcsAnnotateResponse notification) issued by the server (acting 



as an agent entity). The response must be returned within a configured 
time limit or the request will time out. Any required data can be returned 
(subject to the limits of the protocol) All ECS data types are supported 
(string, integer, real, time, duration, Boolean, list, tuple, etc.), including 
any combination of these types. The data in both the request and the 
response is specified as a list. Since all requests use the same CMIP 
event, it is necessary for the designer of the annotate server to specify 
some mechanism to differentiate between requests. The response event 
will include the requesting node name and request ID provided in the 
request event These are used to route the response to the requesting 
annotate node. 

The end user must create the annotate server. Examples of the server's 
agent and manager functions are provided as source code along with 
guidelines. 
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it cart be accessed by the correlation engine. MIBs must con- 
form to the GDMO model (Guidelines for the Definition of 
Managed Objects, ISO/IEC 10165-4, ITU-T X.722) or the HP 
OpenView DM platform will not accept them. Once part of 
the platform, ECS accesses the components of the events 
using the textual names from the MIB registration tree. The 
MIB is described in the article on page 52. 

Language 

Underlying the ECS Designer G LI is a complex and sophisti- 
cated language called ECDL (Event Correlation Description 
Language), which supports the complete specification of the 
correlation circuit including all the dynamic node expressions 
and conditions. ECDL includes data types, operations, and 
functions that allow read access to all component data in 
the events as they traverse the circuit, and to all public data 
within the circuit. (Event attributes can be altered with the 
modify- node.) The ECS Designer ensures that the circuit 
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designer does not need to understand this language in great 
detail. The circuit is specified by the visual interconnection 
of selected nodes. Node parameters are specified wherever 
possible using simple ECDL constructs and supplied library 
functions written using ECDL or actually built into ECDL. 
Advanced users are able to create specialized reusable func- 
tions. The ECDL code produced by the ECS Designer is en- 
crypted in source form and compiled for downloading lo the 
correlation engine. Direct coding using ECDL is not sup- 
ported and cannot be compiled. 

Building and Testing Correlation Circuits 

The ECS Designer (which includes circuit design and simu- 
late modes) is a GUI that allows the circuit designer to use 
a highly productive intuitive paradigm to build a correlation 
circuit by interconnecting primitiv e and compound nodes 
(see Fig. 7). 
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Ill EC'S Designer huilil mode, nodes are selected from llie tool 
palette, placed on the canvas, and interconnected to form 
the correlation circuit. Subsets of the circuit can be encap- 
sulated as compound nodes to improve readability, imple- 
ment lop-down design rules, or promote reuse. Each node 
must be configured with appropriate values or expressions 
for its parameters. The general flow of events is determined 
by the circuit layout, subject to the conditions imposed by 
individual node parameters. 

When the circuit is complete, the ECS Designer can be 
switched tQ simulate mode. In this mode, events can be 
input to the circuit to allow visualization of the How of 
events through the circuit. 

Various visual techniques are used to provide circuit opera- 
tion feedback to the circuit designer. Events can be input in 
various modes: stepped by event or by time, free-run at 
selectable speed until a breakpoint, and others. The status 
of each node can be examined at any time. For instance, the 
contents of table nodes can be examined, the number of 
events through various polls can be checked, and so on. 

In the simulate mode, events are input to the circuit from an 
input event log. The circuit designer can view both the input 
events and the correlated output events by means of associ- 
ated event browsers. 

The simulation is performed using a fully functional correla- 
tion engine, except that the engine does not free-run. The 
engine's notion of lime is under the control of the simulator. 



When a circuit has been developed and tested, the ECS 
Designer is used to compile the circuit so that it can be 
down-loaded into correlation engines, possibly in remote 
locations. 

The event log that is input to the ECS simulator is in a struc- 
tured ASCII format, allowing the events to be niiuiually 
created or edited. It is desirable to use a log of real events, 
and to colled them automatically. Support is provided to 
collect real events in the required format. It may lie neces- 
sary to make some simple edits to this event log to Si m ulate 
the possible worst -case transit delays. 

HP OpenView DM Interlacing 

The correlation engine is integrated with the III' ( ipenView 
Distributed Management (DM) postmaster, ensuring thai 
correlation is applied at a common point so that all events 
can be subjected to correlation (see Figs. 2 and 8). A cor- 
relation engine can be installed wherever an IIP OpenView 
DM platform is installed. The distributed nature of HP Open- 
View DM event management services allows a distributed 
hierarchy of correlation engines to be readily implemented. 

Adding correlation engines to the IIP < IpenView DM post- 
masters is transparent to existing agent and manager enti- 
ties communicating via the postmasters, except that events 
can now be correlated. If the loaded correlation circuit were 
to pass all events, there would be no observable difference 
in the operation of these entities, or in the events being 
generated and received. 
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Network Management Applications 
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Fig. 8. Event routing to and from HP OpenView Event Correlation 
Services. 

The HP OpenView DM platform is described in the article on 
page G. 

Events entering the postmaster are routed to the correlation 
engine where they may be accepted into the engine depend- 
ing upon the configuration of the circuit input ports (see 



Fig. 8). Confirmed CMIP events are immediately returned tr> 
the postmaster by the correlation engine. It is normally 
expected that a management entity will receive a confirmed 
event, and that the confirmation is returned as a consequence 
of some action having been taken, frequently by an operator. 
Typically, if the confirmation is not returned, the agent entity 
that generated the event will issue another (possibly differ- 
ent) event. The operation of the agent entity may be effected 
by the absence of the confirmation. If confirmed events 
were accepted into the correlation engine where they were 
subsequently suppressed as part of the correlation, the con- 
firmation would not be relumed since the normal receiving 
entities would never see the event. Conversely, if the cor- 
relation engine generates the confirmation, the agent entity- 
can modify its function based upon the assumption that an 
operator has seen the event and taken appropriate action. 

The input ports of the correlation engine must be configured 
to accept all events received or they will be filtered out and 
discarded by the engine. Where significant events are ex- 
pected for which correlation has not been designed into the 
circuit, a branch of the circuit can be arranged as a pass- 
through to transmit all events not explicitly handled by the 
other circuit branches. 
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A Modeling Toolset for the Analysis 
and Design of OSI Network 
Management Objects 

To deal with the complexity of network management standards and the 
increasing demand to deploy network management applications quickly, 
analysts and designers need a set of tools to help them quickly and easily 
model, define, and develop new network management objects. 

by Jacqueline A. Bray 



The HP GDMO (Guidelines for the Definition of Managed upon them are defined. The managed resources might be 

Objects) Modeling Toolset (GMT) is the first tool in the HP physical (e.g.. a router or workstation) or logical (e.g., a 
i ipenView T.MN (Telecommunications Management Network) software process). A managed resource might also repre- 
developer tool chain ( Fig. 1 ). This toolset consists of a set of sent a collec tion of different resources. Other elements 

might he managed that are not actually resources but are 
required to support management functions, such as an event 
log. These requirements are translated into a GDMO object 
model, with the managed resources represented as managed 
objects. The managed objects define the interface to a man- 
aged resource. 

GDMO 

Tlie Guidelines for the Definition of Managed Objects is an 
ISO standard (1SO/IHC 101(55-4 (ITU X.722)) 1 that defines 
how network objects and their behavior are to be specified, 
inc luding the syntax and .semantics. This specification lan- 
guage allows network object designers and manager/agent 
implementers to communicate designs and build upon exist- 
ing designs. GDMO is an object-oriented environment, using 
the concepts of inheritance, containment, and encapsulation. 
It is used to define: 

• Managed object classes for managed resources 

• Attributes and behaviors of a managed object 

i < operations that can be performed on an attribute at object 

• Notifications (events) an object might issue 

• Relationships with other managed objects 

• The names of object instances. 

GDMO is organized into templates, which are standard for- 
mats used in the definition of a particular aspect of (he Ob- 
ject, with rules for how these templates refer to each other. 
A complete object definition is a combination of interrelated 
templates. There are nine of these templates. 

• Miiiini/ril object class templates define a model for managed 
object instances that share the same characteristics. The 
inheritance relationships with other managed object classes 
are specified, along with the packages that define the class 
characteristics. 

• Package templates are groups of logic-ally related sets of 
behaviors, attributes, attribute groups, actions, notifications, 
and parameters. Willi each attribute is a property list of 
valid operations (Get, Replace, Add. and Remove), initial values, 
and other value characteristics. 
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integrated tools designed to aid developers in the analysis 
and design of OSI network object models. The key compo- 
nents of the toolset are a graphical modeling tool, import 
and export facilities, and a conformance report generator. 
The t<x>ls operate independently of other IIP Open View prod- 
ucts so that network specifiers can work independently of 
implementers. This artic le provides an overview of the net- 
work modeling process. GDMO, and the modeling tools. 

The Modeling Process 

The first step in developing a network object model is the 
analysis of the environment to be managed. The network 
and system resources to be managed are identified and their 
characteristics and the operations that can be performed 
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• Behavior templates describe, in textual form, the behavior 
of a component. 

• Attribute templates define an actual data element of an 
object, including its syntax and behavior. 

• Attribute group templates define a set of attributes to allow 
operations to be performed on the group as a whole. 

• Aetion templates define additional operations for a managed 
object that cannot be modeled using the standard operations 
defined in the package template. 

• Notification templates define unsolicited events that may 
be sent by the agent. 

• Parameter templates define error conditions specific to the 
object and extend the definition of information used by 
actions and notifications. The context within which this 
parameter can be used is specified. 

• Name bind inn templates define where an object may be lo- 
cated in the global containment tree, along with the attribute 
used to distinguish object instances. These templates also 
specify rules for the creation and deletion of the object 
instances. 

An example of each of these templates can be found in 
Appendix A, which shows a portion of a (J DMO definition 
for a UNIX® password file (i.e., /etc/passwd). The details of 
the information to be exchanged between the manager and 
agent are defined using ASN.l (Abstract Syntax Notation 
One). 2 ASN.l is a formal description language used to define 
data types to be exchanged between systems. It includes 
primitive data types, such as integer and Boolean, and allows 
new data types to be constructed fiom these types. The data 
types are grouped into one or more ASN. 1 modules within a 
GDMO definition. In the example in Appendix A, there is one 
ASN.l module named PasswordFilelnfo. The GDMO templates 
reference ASN.l data types by prefixing the data type with 
the ASN.l module name (e.g., PasswordFilelnfo. LoginNameSyntax 
in the loginName attribute template). 

Other ISO standards also relate to the definition of manage- 
ment object models. For example, The Management Informa- 
tion Model 11 is a companion document that defines modeling 
concepts, principles of naming and relationships, and scoping 
and filtering. Another example is the standard for the Defini- 
tion of Management Information. 4 This standard defines, in 
GDM( ) and ASN. 1, a set of managed object classes to be used 
as superclasses. It includes an object class named top, from 
which every other managed object class ultimately derives. 
The other classes form an inheritance hierarchy, with top as 
the root. The object class top includes attributes for object 
instance naming, which the other classes inherit The set of 
rules for defining managed objects is referred to as the 
Structure of Management Information. 

The Toolset 

The GDMO modeling toolset stores the GDMO and ASN.l 
definitions in an object dictionary, which acts as a central 
repository for all the tools (see Fig. 2). The toolset allows 
concurrent access to the tools and object dictionary and can 
be configured as a client/server architecture. GDMO and 
ASN. 1 definitions are organized within documents. An im- 
port facility allows external standard and user-defined GDMO 
document files, such as ITU-T X.721, to be loaded into the 
object dictionary. (X.721 and other GDMO standards are 
included with the toolset.) New object classes can inherit 
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Fig. 2. The GDMO modeling toolset. 

from any object class in the object dictionary and reference 
other templates and data types for consistency and reuse of 
specifications. Within the toolset, each document has a short 
alias name to simplify references to documents. Object defi- 
nitions can be added to new or existing documents. 

The graphical modeling tool can be used to learn the syntax 
of the GDMO language, to explore existing GDMO docu- 
ments, and to create new ones. A template window exists 
for each of the nine GDMO template types. These windows 
show the details of an existing template or guide users in 
creating new templates. For example. Fig. 3 shows the tem- 
plate for a managed object class, with the GDMO keywords 
along the left (requiring no entry) and the specific entries 
for this managed object class entered in the table. Clicking 
the name of one of the referenced templates, such as the 
Characterized By Package template, and clicking on the Details 
button, displays the window for that particular template. 
The Package template window displays entries for several 
template types, including Attributes. Clicking on Details for an 
attribute in that window would display its Attribute template. 
In this way, successively more detailed information can be 
viewed until the lowest level, the ASN.l definition, is reached. 

Browsers for each of the template types can be invoked to 
display a list of all available entries of that type. A filter 
function is available in die browsers to display subsets of 
the complete list. Template entry names can be copied into 
another template window without retyping the name by 
selecting an entry with the mouse and then clicking the 
Insert button in the appropriate template. The Details button 
described above also functions in the same way while in the 
browser windows. This detailed drill-down capability is 
available throughout the tool. 

Two useful features for cross-reference checking the object 
model are the Viewpoint and Inherited Characteristics options. 
Clicking the Viewpoint button, available on all template and 
Viewpoint windows, displays the viewpoint for a selected 
item. In the Viewpoint of Managed Object Class window in Fig. 4, 
the selected object is represented by the vertical bar. the 
templates on the left reference the selected object, and the 
templates on the right are referenced by the selected object. 
The boxes on either side of the vertical bar contain the 
appropriate GDMO keywords. Above each template name is 
the template type (e.g., MOC (managed object class). PKG 
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(package), etc.). The Viewpoint window is helpful when mak- 
ing changes to an object to verify thai those changes will not 
adversely affect other objects that are dependent upon it. 

Clicking Views and then the Inherited Characteristics button, 
available only on managed object class template windows, 
displays the window shown in Fig. 5. The characteristics 
available to a managed object class, whether specialized in 
that object class definition or inherited from an ancestor, 
can be displayed by selecting the characteristics of interest 
(Attributes, Notifications, etc.) from the row of buttons under 
Characteristics to Display and then clicking Compute. The scrolled 
window lists all of the inherited characteristics available and 
where they were referenced. Clicking on a characteristic 
and then the Details button displays its template. 

The graphs available in the GDMO toolset represent three 
distinct and independent tree structures used in OSI system 
management. These graphs are the inheritance graph, the 
registration graph, and the name binding graph. The inheri- 
tance graph (Fig. 6) shows t he inheritance hierarchy of all 
the managed object classes in a selected GDMO document, 
along with any superclasses derived from other documents. 
(All of the tool windows handle referencing across docu- 
ments. When a template is referenced from another docu- 
ment, the template is prefaced with the document alias.) 
Object class nodes can also be added or deleted on this 
graph. GDMO and the GDMO toolset both support multiple 
inheritance, which allows classes to inherit properties from 
more than one superclass. 

The registration graph (Fig. 7) shows part of I he registration 
tree of object identifiers defined in PTU-T Recommendation 
X.721."' An object identifier is a unique ASN.l data type that is 
a sequence of nonnegative integers representing a particular 
object. GDMO describes the registration tree structure 



adopted in the OSI system management standards for allo- 
cating globally unique ident ifiers to components of managed 
object definitions.'' Objects can be registered via die registra- 
tion browser or the registration tree. Registration is typically 
done in the last phase of GDMO modeling, when document 
definitions are stable. 

The name binding graph (Fig. 8) displays the containment 
relationships defined via die name binding template. The 
name binding template specifies a subordinate (contained) 
object and a superior (containing) object, along with an 
attribute of the subordinate object that will be used to name 
instances of that class. The name binding template also speci- 
fies whether object instances can be created and deleted via 
remote management, along with any limitations on those 
actions. For example, it may specify that an object instance 
can be deleted v ia remote management, but only if thai ob- 
ject instance does not contain other objects. This contain- 
ment hierarchy represents the Structure of the Management 
Information Base (MIB). It shows the objects an agent con- 
tains and the hierarchy and containment of those objects, 
which are used not only to define the MIB structure but also 
as a means of unambiguously referencing object instances.' 1 

Once the GDMO document is complete, the semantic checker 
verifies that the specifications are complete and correct. It 
checks references throughout the object dictionary, including 
the detection of templates that are defined but unreferenced. 
The document can then be exported to an ASCII file for sub- 
sequent use by code generators, such as the IIP Open View 
Managed Object Toolkit and other tools. The ASCII file con- 
tains both the GDMO definitions and ASN.l modules. The 
Managed Object Toolkit is described in the article on page 52. 

The remaining tool, the conformance report generator, gen- 
erates printed reports that conform to the ISO standard: 
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Requirements and Guidelines for Implementation Confor- 
mance Statement I'niformas Associated trith Management 
Information (ISO/1EC 101654) (ITU-T X.724 1. Fig. 9 is an 
example of a proforma The designer annotates the compo- 
nents in the report with any additional information that will 
be needed hy the agent developer implementing the compo- 
nent Tlte agent writer will indicate in the proforma report 
the level of conformance to the definitions. 

Conclusion 

Developing a network object model and the associated 
<j|>M< i specifications is a complex process TheGDM" 1 
Modeling Toolset aims to reduce the complexity and lime 
In v o l v ed in this definition hy providing intuitive graphical 
tools and object model verification. 
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Appendix A: A Portion of a GDMO Definition for a UNIX Password File 



passwordEntryManagedObjectClass MANAGED OBJECT CLASS 
DERIVED FROM 

"Rec. X.721 I ISO/IEC 10165-2 : 1992":top; 
CHARACTERIZED BY 

passwordEnt ryPackage ; 
REGISTERED AS { passwordMOCOb j ID 1 } ; 



passwordEntryPackage PACKAGE 
BEHAVIOUR 
ATTRIBUTES 

loginName 

GET, 
password 

INITIAL VALUE 
GET-REPLACE, 



passwordEntryPackageBehav; 



PasswordFilelnf o . passwordlnitVal 



ATTRIBUTE GROUPS 

passwordEntry; 
NOTIFICATIONS 

passwordEntryWasCreated, 

passwordEntryWasDeleted; 
REGISTERED AS { passwordPkgOb j ID 1 ) ; 

passwordEntryPackageBehav BEHAVIOUR 

DEFINED AS "This is a simple agent /manager designed to 
manipulate entries in a UNIX password file, /etc/passwd. 



loginName ATTRIBUTE 

WITH ATTRIBUTE SYNTAX 
MATCHES FOR 
BEHAVIOUR 
PARAMETERS 



PasswordFilelnf o . LoginNameSyntax; 

EQUALITY; 

loginNameBehav; 

loginNameErrorParam; 



REGISTERED AS { passwordAttrOb j ID 1 ) 

passwordEntry ATTRIBUTE GROUP 
GROUP ELEMENTS 
loginName, 
password, 



DESCRIPTION "This is the mechanism whereby an entire password 
entry will be referenced in a single call."; 
REGISTERED AS ( passwordAttrGroupOb j ID 1 ) ; 



readObjectsFromDisk ACTION 
BEHAVIOUR 
PARAMETERS 

WITH INFORMATION SYNTAX 
WITH REPLY SYNTAX 



readob j ect sBehav ; 
readOb j ect sEr rorParam; 
PasswordFilelnf o. FileNameSyntax; 
PasswordFilelnf o . SuccessSyntax; 



REGISTERED AS { passwordActionOb j ID 1 } ; 

passwordEntryWasCreated NOTIFICATION 

BEHAVIOUR passwordWasCreatedBehav; 

WITH INFORMATION SYNTAX PasswordFilelnf o . LoginNameSyntax; 

REGISTERED AS { passwordNot if yObj ID 1 } ; 

loginNameErrorParam PARAMETER 

CONTEXT SPECIFIC-ERROR; 

WITH SYNTAX PasswordFilelnf o . LoginNameError ; 

BEHAVIOUR loginNameErrorBehav; 
REGISTERED AS ( passwordParamOb j ID 1 ) ; 

passwordEntryNameBinding NAME BINDING 

SUBORDINATE OBJECT CLASS passwordEntryManagedObjectClass; 
NAMED BY SUPERIOR OBJECT CLASS passwordRootManagedOb j ectClass ; 

WITH ATTRIBUTE loginName ; 

BEHAVIOUR passwordEnt ryNameBindingBehav; 

CREATE WITH-REFERENCE-OBJECT; 

DELETE DELETES-CONTAINED-OBJECTS; 
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REGISTERED AS { passwordNasneBindObj ID 1 } ; 



— ASN.l Definitions 
PasswordFilelnfo 

DEFINITIONS : : = BEGIN 

maxName Length 
LoginNameSyntax 



l n n 4 i u iooi l l ) 

INTEGER : : = 8 

::= GeneralString (SIZE(maxNaineLcngth) ) 



passwordBaseObj ID OBJECT IDENTIFIER { 1 3 6 1 4 1 11 1001 ) 

passvrardAttrObjID OBJECT IDENTIFIER : := ( passwordBaseObj ID 2 } 

passwordMOCObjID OBJECT IDENTIFIER ::= { passwordBaseObj ID 8 ) 



END 

— The passwd example is provided with various HP OpenView TMN products. 
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A Toolkit for Developing TMN 
Manager/Agent Applications 



Developing manager and agent applications for telecommunications 
network management that conform to standards can be a time-consuming 
task because of the number of APIs and data types involved in dealing 
with network data and protocols. The HP OpenView Managed Object 
Toolkit aids and accelerates the development of these TMN applications. 

by Lisa A. Speaker 



Telecommunications Management Network (TMN ) applica- 
tion developers have to implement large, complex solutions 
to manage today's heterogeneous and distributed telecom- 
munication networks. Telecommunication service providers 
(Carriers) rely On interoperability standards to integrate and 
deploy these solutions in a heterogeneous environment. 
Developing these solutions to conform to standards is a 
time-cons urn i ng task. 

This article will provide an overview of the challenges in- 
volved in developing OSI-based TMN applications and then 
will describe the IIP OpenView Managed Object Toolkit, 
which can be used to accelerate the development of TMN 
applications. 

Background 

Network equipment providers and network service providers 
historically have developed their own proprietary solutions 
for managing their telephone network equipment. Today, 
however, network equipment may come from different pro- 
viders, and telecommunication network operators manage 
large, heterogeneous, and distributed networks. Thus, the 
main objective lor standards being developed for managing 
telecommunications networks is to provide a framework for 
telecommunications management thai promotes interopera- 
bility. By introducing t he concept of generic network models 
for management, il is possible to perform general manage- 
ment of diverse equipment using generic information models 
and standard interfaces. 

In 1977. the International ( trganization for Standardization 
(ISO) recognized the necessity for standards to enable the 
widespread use of communications networks and, as a re- 
sult, established a subcommittee to initiate the standardiza- 
tion process. Because of the complexity of the environment, 
they concluded that no single standard would be sufficient 
Rather, they decided that the communication functions 
should be partitioned into more manageable components and 
organized as a communications architecture. This architec- 
ture would then form the framework for standardization. 1 

The essential elements of the model were developed quickly, 
but the final ISO Standard (ISO 7498) was not published until 
1984. The International Telegraph and Telephone Consultative 
Committee (CCITT) issued a technically compatible version 
as X.200. The result is a massive set of standards referred to 



as OSI (Open Systems Interconnect) systems management. 
The ISO standards mid the CCITT" recommendations con- 
tinue to be developed with close collaboration. 

The term OSI systems management actually refers to a 
collection of standards for network management that in- 
clude a management service and protocol and the definition 
of a database and associated concepts. The first standard 
related to network management issued by the 1S< ) was 
ISO 7498-4. w hich specifies the management framework for 
I he OSI seven-layer model. Subsequently, the IS( ) issued a 
set of standards and draft standards for network manage- 
ment. A subset of these standards provides the foundation 
for TMN applications. 

The TMN recommendations strive to leverage the OSI sys- 
tems management standards and extend them into the tele- 
communications network management domain. As in OSI, 
the basic concept behind TMN is to provide an organized 
architecture and standardized interfaces, including protocols 
and messages, to achieve interconnection between various 
types of operations systems (OSs) and telecommunications 
equipment for the purpose of exchanging management 
information. 

The OSI systems management standards fall into live 
categories: 

• An OSI management framework and overview, which 
provides a general introduction to management concepts, 
including the OSI seven-layer model 

• The Common Management Information Service (CMIS), 
which provides OSI management services to management 
applications, and the Common .Management Information 
Protocol (CMIP). which provides the information exchange 
capability to suppoti CMIS 

• Systems management functions, which define the specific 
functions performed by OSI systems management, including 
fault, configuration, accounting, performance, and security 
management 

• A management information model, which defines the 
Management Information Base (ML3), a database containing 
information about the resources and elements within the 
OSI environment that need to be managed 

• the CCITI recommendations are now called IIU-I (International telecommunications Umon- 
telecommunicationsl recommendations 
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• Layer management, which defines management information, 
services, and functions related to specific OSI layers. 

The fundamental function within OSI systems management 
is the exchange of management information between two 
entities: the managing system (the manager or requestor) 
and the managed system (the agent or responder) by means 
of a protocol (see Fig. 1). CMIS provides the services, invok- 
able by the management process to initiate management 
requests, and CMIP specifies the protocol data unit ( PDI ' ) 
ami associated procedures for transmitting management 
requests and responses. 

OSI systems management relies heavily on the concepts of 
object-oriented design. A mnnngrrf objrcl class is a model or 
template for managed object instances that share similar 
characteristics. An OSI systems management managed object 
class is defined in terms of its attributes, operations mat t an 
be performed upon it, notifications that it may emit, and its 
relationships with other managed objects. Attributes hold 
the tlata values associated with a specific managed object 
instance and may have a simple or complex structure. The 
tlata type for an attribute is defined using Abstract Syntax 
Notation One (ASN.l). The operations affiliated with a 
managed object class are closely associated with the ( MIS 
services CREATE. DELETE, GET, SET. and ACTION. 

A managed object class can be defined for any resource that 
an organization wishes to monitor or control. A single man- 
aged object class may represent a single network resource 
or a logical representation of many resources. Examples of 
hardware resources include switches, workstations. PBXs. 
LAN cards, and multiplexers. Examples of software resources 
are queuing programs, routing algorithms, and buffer manage- 
ment. Examples of logical resources include a network, a 
route, or a virtual private circuit- 



Fig. 1. The OSI systems manage- 
ment architecture: the manager 
system and Hie managed system 
(agent). 

An agent application provides a view of its associated 
managed object instances. Manager applications are able to 
access the managed object instance attribute values and 
manipulate managed object instances through the manage- 
ment interfaces published by each managed object class. 

The foundation of any network management system is a 
database containing information about the resources and 
elements Lieing managed. In OSI systems management, this 
data base is called the Managi'inrnt Informal ion Bnsr (MIB). 
The MIB is a structured collection of managed object in- 
stances, together with their attributes. The MIB is typically a 
multilevel hierarchy based on the managed object class con- 
tainment relationships defined in the object model. The MIB 
hierarchy is constructed and traversed by using lite object 
instances' distinguishing attributes. For example, in Fig. 2 a 
switchPort object instance is identified by its portNum attribute, 
its associated switchCard cardNum attribute, and its switch 
switchNum attribute (switchNum = 1, cardNum = I, portNum = 2). 

Trie general framework within which a MIB can be defined 
and constructed is referred to as the Structure of Manage- 
ment Information (SMI). SMI identifies the daia types that 
can be used in the MIB and how resources within the MIB 
are represented and named. 

To encourage consistency between managed object defini- 
tions and to ensure the development of object definitions in 
a m;inner compatible with the OSI system management stan- 
dards, the Guidelines for the Definition of Managed Objects 
KiDMO) (ISO/IEC 10165-4, ITU-T Recommendation X.722) 
has been developed. This standard provides a formal specifi- 
cation language for defiiting the interface for an OSI managed 
object class and the semantics for documenting the attributes 
and operations (behaviors) associated with a managed object 
class. The specifical ion also defines the relationships among 
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Fig. 2. Tlie contents of a subset of an agent's Management 
Information Base fMlB) showing a containment tree made 
up of object instances and their attributes. 

managed object classes in the management domain. See the 
article on page 43 for more about GD.MO. 

OSI Application Development 

OSI application development falls into two major categories: 
manager development and agent development. This section 
describes the development of the agent and manager applica- 
tioas wilhout the assistance of a toolkit. Development with a 
toolkit is discussed in the next section. 

Manager development involves the development of applica- 
tions thai issue management requests and process agent 
responses and notifications. Notifications are messages 
transmitted by agent applications when some trigger, such 
as a threshold or an error condition, has been tripped. 
Manager applicalion developers must complete (he lasks of: 
Developing the user interface through which managemenl 
requests can be initiated and the status of managed objects 
can be viewed 

Developing the underlying communications for issuing 
requests and processing responses and notifications. 

Agent development involves the development of the appli- 
calion that manages the managed object instance data, 
maintains its portion of the MIB, processes inbound man- 
agement requests, and emits notifications as necessary. 
Agent application developers must complete the tasks of: 
Defining ( usually in GDMO) the managed object classes 
associated with the resources managed by the agent 
application 

Developing the underlying communications for processing 
management requests 

Monitoring managed resources and emitting notifications 
as appropriate. 

X/Open * . an independent, worldwide, open systems organi- 
zation, pro\ides application programming interfaces (APIs) 



lo facilitate the development of OSI applications. A primary 
objective of X/Open is to promote the portability and inter- 
operability of OSI applications at I he source-code level. For 
OSI systems management applic ation developers, X/Open 
provides the X/Open OSI Abstract Data Manipulation (XOM) 
APIs and the X/Open Management Protocol (XMP) APIs. 2 ' 5 

XOM is a C-language interface specifically designed for use 
with application-specific APIs that provide OSI services, 
such as XL 400 and CMIS. The XOM API is a set of structured 
information objects and functions for accessing objects and 
sluelding programmers from much of the complexities of 
manipulating tlie underlying ASN.l datatypes. 

XMP provides the TMN application developer with a C-lan- 
guage interface to the underlying management services con- 
sistent with the CMIS/CMIP and the Simple Network Man- 
agement Protocol (SNMP). The XMP API is designed to be 
used and implemented with the XOM API. XOM objects 
serve as the parameters for the XMP management service 
functions (see Fig. 3). 

Manager applications initiate management requests and 
process responses returned from agent applications. XMP 
functions that support issuing management requests include: 
i mp_create_req( ): Initiates a management request to create a 
managed object instance 

mp_geweq( ): Initiates a management request lo get data 
from a managed object instance 

mp_set_req( ): Initiates a management request to set attributes 
in a managed object instance 

mp_receive( I: Receives the agent's response to support asyn- 
chronous requests or a notification emitted by an agent. 

XOM objects, defined as C structures, must be created and 
passed to these functions to transfer the details of the man- 
agement request . For example: 

mp_create_req( ) requires a CMIS-Create-Argument XOM object 
and is returned a CMIS-Create-Result XOM object 
mp_get_req( I requires a CMIS-Get-Argument XOM object and 
is returned a CMIS-Get-ResultXOM object 
mp_set_req( I requires a CMIS-Set-Argument XOM object and 
is returned a CMIS-Set-Result XOM object. 



xmp_api (xom_object ) 



Or 



1 





J 



1 





Fig. 3. Tlie relationship bet ween XOM objects and XMP manage- 
ment functions. XMP functions use XOM objects as parameters lo 
send the details of a manager's request via either a CMIP or an 
SNMP protocol stack. 
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i mp_recerve( I requires a CMIS-XXX-Result XOM object, with 
lype depending on the response received, and is used for 
receiving asynchronous requests. 

Fig. 4 shows the specification for the CMIS-Get-Argument XOM 
object class. The specification shows that the GET request 
XOM object class specification also contains references to 
oilier XOM object classes. To construct a CMIS-Get-A/gumem 
XOM object, all of its contained XOM objects must also be 
constructed. The complexities of developing applications 
using the XOM API can be seen. The developer is challenged 
with the tedious task of traversing several levels of nested 
XOM objects either to prepare a request or to extract data 
from a response. 

When developing agent applications using the XMP/XOM 
APIs, the agent developer is responsible for creating func- 
tions to receive the request, determine the type of request 



CMIS-Get-Argument XOM Ob|ect Class: 
XOM Attribute Value Syntax 



base-Managed- Object lObject-ClassI 
Object-class 



base-Managed- Object lObject-lnstance) 
Object-Instance 



access-Control Object (Access-Control I 

synchronization Enum ICMIS-Syncl 

scope Object (Scope) 

filter Object ICMIS Filler) 

attribute-Id-List Object (Attribule-ld-Listl 

Attribute -Id-List XOM Object Class: 

XOM Attribute Value Syntax 

attribute-Id Object (Attribute-Id) 



Class of object desig- 
nated as starling 
point of request 

Identifier of object 
designated as starting 
point of request 

Permission and secu- 
rity information 

How to synchronize 
selected object 
instances 

Subtree to be 
searched 

Characteristics to 
test attributes 

Attribute values to be 
returned 



Identifier lor a manag 
object attribute 



An instance ol an Atlribute-ld-List object will contain zero or more attribute 
identifiers, designating which attribute values to retrieve ill the managed 
object instance. Each attribute identifier must be constructed and has the 
following form. 

Attribute- ID XOM Object Class: 



I CREATE. GET. SET. ACTION. DELETE, etc. ). validate the request, 
and process the request. In validating die request, the agent 
developer must determine, for example, if the request is for 
a valid object instance in the agent's management domain, 
or confirm that a SET request has been received on a modifi- 
able attribute. A significant portion of the agent development 
task is in the implementation of request validation. 

The agent developer mtist also manage the application's 
representation of the containment tree, which is the in 
process structure holding the representation of the managed 
objects and their associated attribute values (see Figs. 1 
and 2 ). As management requests are received, the agent 
application must operate on the associated managed object 
representation in the agent's containment tree to perform 
operations such as: 

• Create new entries in the containment tree as CREATE 
requests are received 

• Delete entries in the containment tree as DELETE requests 
are received 

• I'pdate entries in the containment tree as SET requests are 
received 

• Traverse die containment tree when scoped and filtered 
requests are received. 

A scoped request operates recursively on an entire branch 
of the containment tree, starting at a designated base man- 
aged object. A filtered request designates criteria Uiat man- 
aged objects must have to have a management operation 
performed. Filters are an optional facility that the agent can 
provide. Scoping and filtering allow multiple managed ob- 
jects to be selected and operated upon in servicing a single 
management request 

After processing the request, the agent developer must 
prepare the response by constructing the associated XOM 
objects and then use the XMP API to issue the management 
response. 

The XMP API provides a collection of functions to support 
agent development, including: 

mp_receive( I: Receives the indication of a management 
request 

mp_create_rsp( I: Transmits a response to the managers 
create request 

mp_gel_rspl I: Transmits a response to the manager's GET 
request 

mp_set_rsp( I: Transmits a response to a manager's SET request 

As in the manager scenario, the data received by the agent 
will be in the form of an XOM ob ject, and the agent applica- 
tion developer must, prepare an XOM object to return to the 
manager application after servicing the manager's request 



XOM Attribute 
global-Form 

local-Form 



Value Syntax 

String (Objecl-ldentifierl 

Integer 



A registered attribute 
type identifier 

Integer identifier 
defined as part ol the 
application context 



An instance of an Attribute-Id object will designate the attribute to be 
retrieved eithor through its global-Form or its local-Form. 



Fir. 4. A spi-i-ificatuui I'm tin- CMIS-Get-Argument V i\l uLijert - bss. 



IIP OpenView Managed Object Toolkit 

As noted above. OSI systems management standards use 
object-oriented techniques to model applications in terms of 
managed objects, which represent the resources in a net- 
work. This makes object-oriented programming techniques, 
including the C+ + programming language, a natural imple- 
mentation choice to use for development, starting from 
object analysis to application coiling. 
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Historically, developers implementing standards-based osi 
applications have been required to implement the entire 
management application, agent, and manager from scratch, 
using the complex XUM/XMP APIs and C bindings, as de- 
scribed above. 

However, the OSI systems management standards precisely 
define a generic Structure and behavior that apply to all 
agent applications. The agent developer's task can be greatly 
simplified by implementing the generic pieces with reusable 
software components, which can be assembled to build 
agent applications. In addition, GDMO is provided for for- 
mally defining the specific managed object class attributes 
and interfaces. Given a GDMO specification, it is possible to 
define a C++ class mapping representation of I he GDMO 
managed object classes. 

These two fundamental philosophies form the foundation 
for the HP Open View Managed Object Toolkit (MOT). The 
Managed Object Toolkit supplies: 

• An object-oriented agent application framework that pro- 
vides the general-purpose, reusable software components 
that make up the generic aspects of an OSI agent application 
(An application framework is a generic application thai can 
be tailored to meet specific requirements. It handles all 
generic operations lhal are common to all applications in 

a specific domain. The agent framework is provided as a 
library with the Managed Object Toolkit.) 

• A GDMO-to-C++ and an ASN. l-lo-C++ code generator that 
provides the OSI application developer with a C++ interface 
for the implementation of the specific- behaviors of a man- 
aged object in an agent application and C++ classes for 
preparing management requests in a manager application 

• An agent application generation capability lhal merges the 
generic framework and the specific GDMO-based generated 
C++ classes inlo an operational agent application. 

Agent application development, which previously had taken 
programmers weeks, or even months. 10 code using the XMP/ 
XOM APIs can now be generated in a matter of minutes or 
hours. The Managed Object Toolkit allows agent developers 
to focus on the implementation-specific details of Iheir ap- 
plications, since they no longer need to be concerned with 
the tedious task of using the XMP/XOM APIs to implement 
the CMIS communications model. 



The Agent Development Process 

Using the Managed Objeci Toolkit, agent development is 
accelerated with a simple five-step process (see Kig. '>): 

1. Define the GDMO managed object class specifications. The 
IIP OpenView GDMO Modeling Toolset (GMT) can greatly 
simplify the design of managed object classes by providing a 
graphical, forms-based interface for defining and browsing 
GDMO managed object class definitions. It also provides a 
graphical representation of the object class inheritance and 
managed object naming hierarchies. The IIP OpenView 
GDMO Modeling Toolset is described in the article on 

page 43. 

2. Submit the GDMO object model to the Managed Object 
Toolkit code generator. This will generate C++ class repre- 
sentations of the GDMO managed objeci classes, an agent 
main! I function, makefiles to compile lite agent executable, 
and an object regisl rat ion file lor the IIP OpenView Distrib- 
uted Management Platform's managed objeci directory ser- 
vice. The HP OpenView Distributed Management Platform is 
described in the article on page 6. 

•i. Run the provided makefile, which compiles an operational 
"default" agent, so-called because it implements default be- 
haviors for the managed object interfaces. 

4. Register the agent's objects with the HP OpenView Dis- 
tributed Management Platform's objeci directory service, 

5. Hun file agent application. 

The executing agent is now ready to accept management 
requests, including CREATE, DELETE. GET, SET. and ACTION. Since 
the agenl application is also tightly integrated With the HP 
OpenView Distributed Management Platform, il is able to 
leverage platform services immediately, such as the objeci 
registration service for object location transparency and 
event muling through the event managemenl services. See 
the article on page 31 for more about event management 

Managed Object Toolkit Agent Capabilities 

The Managed Object Toolkit agent framework handles all 
aspects of the underlying management request and response 
communications between agenl and manager, relieving the 
programmer of significant coding effort, including: 
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Receiving CMIS requests I CREATE. DELETE. GET, SET. ACTION, 
etc.). and routing them to the appropriate CMIS service 
handler 

Validating requests and transmitting standard ('MIS errors 
when invalid requests are received (For example, receiving 
a GET request on an attribute in a nonexistent managed 
object instance will generate a standard NO-SUCH-OBJECT- 
INSTANCE error message.) 

Creating and managing the agent 's management information 
tree, which In ilds the managed object instances ami their 
attributes representing the resources managed by the agent 
Supporting scoped and filtered requests in which a single 
request can be routed to several managed object instances 
Preparing and transmitting responses, including packaging 
multiple replies in response to a scoped request 
Emitting standard CMIS notifications when managed object 
instances are created, or deleted, or when an attribute value 
is modified. 

By providing the CMIS communications handling infrastruc- 
ture, the Managed < Ihject Toolkit frees the programmer from 
the tedious task of implementing code for processing man- 
agement requests and responses and allows the developer to 
focus on the value-added specific agent functionality. 

Customizing the Managed Object Toolkit Agent 

Because Specific managed object behaviors cannot be com- 
pletely specified using GDMO, the Managed Object Toolkit 
agent framework and the generated classes cannot fully 
implement managed objects on their own. The framework 
provides a default object behavior, and the Managed < )bjecl 
Toolkit C + + code generator provides a code skeleton for the 
implementation. The complete agent application is buiH l>y 
generating the agenl skeleton code from the GDMO specifi- 
cation and then customizing the generated code stubs (C+ + 
methods). Developers can also integrate Managed I ihject 
Toolkit-provided classes lo implement communications with 
external devices (supported through Standard file descrip- 
tors) and implement a cooperative multitasking agent. 

For example, if a managed object class called switchPort in- 
cludes an attribute called packetsOut which was defined in the 
GDMO specification to be "getlable" (see Fig. 2), the Man- 
aged Object Toolkit generates a file called MOC switchPort. exx 
and includes an empty method called geLpacketsOutl ): 

MOC. switchPort .cxx (filename) 

virtual void Mot switchPort C: :get packetsOut ( 
OVmotMoGetResultC & result_r) 

( 
) 

If the developer wishes to override default behavior of the 
( MIS GET request for the packetsOut attribute to query a regis- 
ter in the associated physical device, the geLpacketsOutl ) 
met hod is easily customized. This method includes a 
response parameter, to which the program mer assigns 8 
response value, and the Managed Object Toolkit agenl 
framework will appropriately package the response and 
return it to the requesting manager application. 

The Managed Object Toolkit prov ides significant value for 
processing requesls. especially if a get.packetsOut request is 
part of a scoped request, which is a single management 
request that will operate, potentially, on several managed 
object instances in the agent. The agenl application must 



route the request to all of the relevant managed object in- 
stances, process the request, gather each of the individual 
responses, package them, and return them to the requestor. 
With the X< )M/X.MP APIs, the agent developer is required to 
implement the entire process, gadier all of the responses, 
package them, and transmit the multiple responses to the 
requestor. With the Managed Object Toolkit, the agent devel- 
oper is only required to implement the handlers for each 
individual request. -Since the agenl framework manages all 
aspects of the request and response communications, the 
framework will trac k the scoped request, route it to ail 
appropriate object instances in the Managed Object Toolkit- 
managed containment tree structure, collect all of the indi- 
vidual responses appropriately, and transmit the composite 
response to the requestor. The Managed Object Toolkit- 
based agent developer is required to implement only the 
actual details of each attribute's request handler. 

Implementing an ACTION operation provides another good 
scenario. The CMIS ACTION service provides a general pur- 
pose object interface for implementing any operation in a 
managed object instance. For example, an action may be 
defined to reset a port on a switch. As in the GET scenario, 
the Managed Object Toolkit generates an empty C+-+ method 
for the programmer to fill in the specific details for servicing 
the ACTION request But unlike the GET scenario, the stan- 
dards cannot specify the appropriate response to an ACTION 
operation, and GDMO does not provide syntax for the spe- 
cific implementation of an ACTION operation. Therefore, it is 
entirely the agent developer's responsibility to provide the 
implementation details associated with an ACTION request 

The following generated method provides the programmer 
with the action information the management application 
passed along, and as in the GET scenario, an empty result 
object that the programmer fills in to transmit the agent's 
response. The MOT generates a file called MOC^switchPort.cxx, 
which includes the empty met hod resetPorLactionl I. 

Moc_switchPort .cxx (filename) 

virtual void Mot switchPort C::resetPort action! 
const Mot resetPort InfoC*actinfo.p, 
OVmotMoActResultC & result_r) 

{ 
1 

Again, the Managed Object Toolkit provides significant 
value, requiring the programmer to implement only the de- 
tails of the action handler and assign the action response, 
allow ing the programmer to disregard implementing any of 
the ( 'MIS communications processing. 

Managed Object Toolkit Agent Framework 

In typical object-oriented design philosophy, the agent 
framework c an be decomposed into several supporting 
frameworks (see Fig. ti). Each subframework, implemented 
as a class library, provides a particular category of function- 
ality that contributes lo the overall agent request processing 
task. 

The agent framework is provided as a library with the Man- 
aged Object Toolkit and is made up of the following compo- 
nents: 

CMIS Service This class library provides classes that enable 
convenient access to the CMIS services. Il contains base 
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Fig. 6. Managed Object Toolkit frameworks. 



classes thai define the CMIS services and subclasses that 
implement the CMIS services using the XMP API. 

CMIS Transactions. This class library provides classes that 
implement the incoming CMIS requests. It provides an agent 
application with the functionality' to process the receipt of 
CMIS CREATE, DELETE. GET, SET, and ACTION indications. 

Containment Tree Framework. This class library provides an 
infrastructure for developing a containment tree representa- 
tion. It also provides concrete classes that implement an 
in-nientory representation of the containment tree. 

Management Information Syntax Framework. This class library 
provides the infrastructure for developing C++ classes that 
represent syntaxes specified in ASN.l ( e.g.. attribute v alues, 
action information, and action reply syntaxes). It provides 
base classes for representing ASN.l syntaxes. 

The Managed Object Toolkit C++ class generator generates 
C++ classes representing ASM. 1 types defined in the GDMO 
specification. These C++ classes are derived from the base 
classes provided in the management information syntax 
framework (see Figs. 2 and 7). Fig. 7 illustrates how the 
Managed Object Toolkit generates C++ classes for GDMO- 
defined attributes. All toolkit-generated attributes will be 



derived from the OVmotAttC C++ class provided by the 
Managed Object Toolkit. 

Managed Object Framework. This class library provides an 
infrastructure for developing managed object implementa- 
tions. It provides C++ base classes for representing man- 
aged object instances and managed object metadata. 

The Managed Object Toolkit C++ class generator will gener- 
ate C++ classes representing t he GDMO object classes de- 
fined in the GDMO specification. These C++ classes will be 
derived from the base classes provided in the managed ob- 
ject framework. The C++ inheritance hierarchy reflects the 
GDMO specified inheritance hierarchy. For example, Fig. 8 



MOT-Provided Framework C++ Class tor Attributes 



MOT-Generated GOMO-Based Attribute C++ Class 




MOT packelsOut C 



Fig. 7. The inheritance hierarchy of C++ classes from the base 
classes provided in the management information Syntax framework. 
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The conununicatioiis framework classes allow the devel- 
oper to create a pseudo multitasking, event -driven interface 
for communicating with external devices. 

Common Application Environment This > lass library provides 
facilities for multilevel tracing and logging. 

Foundation Types. This class library provides classes for rep- 
resenting common data structures such as lists and strings 
and classes for memory management and reference counted 
objects. It is based on the ( >SE class libraries for C-+. 



MOT C++ Inheritance Hierarchy 




Mot swilchPart_C 



MOT-Provided Framework C++ Class 



MOT-Generated GDMO-Based Managed 
Ob|ect C++ Class 



MOT-Generated GDMO-Based Managed 
Object Class 



Fig. 8. The C++ GDMO inheritance hierarchies Of the (iDMO-defiucd 
switchPort managed objerl class. 

shows the C++ inheritance hierarchy for Ihe GDMO-defined 
switchPort managed object class. In the GDMO specification, 
the switchPort managed object class is derived from the top 
managed class. Notice Ihe similarity in the GDMO-defined 
inheritance hierarchy and the C++ inheritance hierarchy 
generated by the Managed Object Toolkit. 

Tin 1 managed object framework uses C+ + classes from the 
management information syntax framework to represent 
attribute, action, and notilicalion syntaxes. 

CMIS ASN.1 Types. This class library provides specializations 
of the ASN.l framework classes for representing CMIS argu- 
trtentS (e.g.. CMIS-Create-Argument and CMIS-Get-Argument). 

Communications Framework. This class library provides an 
infrastructure for developing C++ classes thai are responsible 
for controlling communication with external dev ices. It 
coordinates between objects responsible for different com- 
munication etnlpoints (file descriptors) using an event -driven 
environment, which encapsulates the handling of the I'NIX" 
select! I {taction. The library also includes concrete classes 
for handling communication with the IIP OpenView Distrib- 
uted Management Platform process management functions. 

The communications framework also provides an abstract 
tasking class, based on I'SI.'s U NIX System laboratories) 
task library, which can be leveraged to implement a coopera- 
tive multitasking application. Each task is cooperative, in 
that it owns control of a process until it exits or explicitly 
gives up control. The Managed Object Toolkit CMIS trans- 
actions are a collect ion of concrete task classes developed 

for processing < mis requests. 



Using The Frameworks 

The class libraries are lev eraged by the Managed Object 
Toolkit agent library for processing manager requests. Many 
Of these classes are also externally visible, allowing applica- 
tion developers to leverage them for their own agent devel- 
opment needs. 

For example, when a CMIS GET request is received, the 
agent's communications framework will receive and identify 
the get-indicate, and then construct and initiate a Managed 
Object Toolkit-denned CMIS get-transaction object instance. 
This get-transaction object will manage the overall processing 
of the GET request, interacting with the containment tree 
framework. Ihe managed Object framework, and the manage- 
ment information syntax framework to complete the pro- 
cessing of the GET request. (The C++ object class representa- 
tion of the managed object instance and the GET ham Met for 
this request are contained in ihe managed object framework, 
while the syntax associated with the attribute value is held 
in the management information syntax framework.) 

An agent developer desiring lo implement a multitasking 
interface to external entities, such as devices or databases, 
cart derive a user-defined task class from the Managed ( )b- 
ject Toolkit's abstract tasking base class. The application 
developer then constructs and initiates tasks in Ihe applica- 
tion code, as in the following code fragment, 

myTask. hxx (filename) 

myTaskC: public OVrnotTxnC 
{ 

public : 

myTask ( ) ; 
execute ( ) ; 

private: 

}; 

myTask. exx (filename) 
myTaskC : : execute! ) 
{ 

// provide code for task implementation 

) 

The following code shows the construction and invocation 
of the above task in one of the ( MIS senil e handling 
routines. 

MOC_switchPort . exx (filename) 
virtual void Mot switchPort _C :: get_packetsOut ( 
OVmotMoGetResultC & result_r) 

( 

myTask atask; // construct a task 
atask . execute ( );// run task 

} 
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The communications framework provides a communication 

coordinator that encapsulates the Unix select! i interface. 

Tile communication coordinator is used by the Managed 
Object Toolkit agent framework to receive and process in- 
coming CMIS requests. 

The application developer can also use the communications 
coordinator to process ponCMlS-oriented communications 
within the agent application. An example of this would be 
communicating to an external device through a serial inter- 
face. The agent developer need only register the opened file 
descriptors with the Managed Object Toolkit-provided com- 
munications coordinator and implcmenl the associated com- 
munications handler (read, write, and exception). Then 
through Hie registration and callback mechanism, the com- 
munication endpoint processing code will be executed when 
the file descriptor triggers select* I as in the following code. 

somecc.hxx (filename) 
SomeCC : OVmotCC 
t 

public : 

SomeCC ( ) ; 
-SomeCC ( ) ; 

void doReadl int fd ); 
private : 

inc fd; //File descriptor associated 
//with this communication 
//interface 

}; 

somecc.cxx (filename) 
SomeCC : : SomeCC ( ) 
< 

fd = open (...); //open a file descriptor 

OVmotCoordC: : registerCC (fd, 

OVmCoordC : : 0VM0T_KE_RE AD , this ) 
// register file descriptor with MO commnica- 
// tions Coordinator 

// register for read operations, callback to 
// this->doRead ( ) when data is on fd 
) 

SomeCC : : -SomeCC ( ) 
( 

OVmotCoordC : : deRegisterCC ( fd, 

OVmotCoordC: :OVMOT KE READ, this); 
close ( fd) ; 

// deregister file descriptor with MOT 

// Communications Coordinator and close file 

// descriptor 

} 

SomeCC : : doRead ( int f d ) 
{ 

// Receive and process the data buffered on 

// the file descriptor 

} 

When data is sensed on this open file descriptor, the agents 
communication coordinator will call the doReadl I method, 
processing the data on the communications interface. 

Developing Manager Applications 

liilike the agent development process, the Managed Object 
Toolkit does not generate an executable manager applica- 
tion (see Fig. 6). For manager developers, the Managed Ob- 
ject Toolkit provides an Intuitive C++ interface which encap- 
sulates the complexities of XOM object manipulations and 



assists the manager developer in the management commu- 
nications implementation aspect of manager applications. 

Manager developers use the XMP API to issue requests and 
leverage the Managed Object Toolkit to build the XOM ob- 
ject parameters required by the XMP API (see Fig. 3). The 
manager developer has access to: 

• Managed object Toolkit-provided CME3 service classes to 
build request objects and parse response objects 

• Managed Object Toolkit-provided convenience classes, 
which represent the underlying components of the ('MIS 
request objects, including C++ class representations for: 

Fully distinguished names 
Attribute identifier lists 
Attribute lists 

Base managed objects for scoped requests 
Filters 

• Managed Object Toolkit -provided stream-based classes for 
transforming C+ + request objects to XOM request objects 
and XOM response objects lo C++ response objects 

• Managed Object Toolkit -generated GDMO-based C++ 
ClaSSes representing the managed object classes 

• Managed Object Toolkit -generated ASN.l-based C++ classes 
representing the syntaxes associated with the managed ob- 
ject attributes, actions, and notifications. 

The following scenario is an example of a Managed Object 
Toolkit-based manager GET request. Note that classes that 
begin with Ovmotare Managed Object Toolkit-prov ided 
classes and classes that begin with Mot are Managed Object 
Toolkit-generated classes originating from Hie (iDMO speci- 
fication. 

Scenario: Issue a scoped GET request lor all of the "I P" ports 
on a specific card in a switch and Fgtum the in and out 
packet counts across ports that have traffic. Note the fol- 
lowing containment relationship (see Fig. 2): 

• A switch contains cards. 

• A card contains ports. 

1. Construct each of the attributes thai make up the fully 
distinguished name for a card in a switch. 

Mot switchNum^C switchNum ( 100 ) ; 

Mot_cardNum C cardNumf 10 ) ,- 

This code fragment assigns switchnum to 11)0 and cardnum to 10. 

2. Construct the fully distinguished name for the port base 
managed object of the request 

OVmotDnC dn; 

dn << switchNum << cardNum; 

3. Construct the list of attribute identifiers associated with 
the attribute values to be retrieved. 

OVmotAttldListC attr_ids; 
attr_ids << Mot_portStatus_id << 
Mot packOut_id << Mot_pac)cetsIn id; 

4. Construct the base managed object identifier of the poll 
associated with the request. Request processing to begin at 
the switch card with cardNum = 10 associated with the switch- 
Num = 100. 

OVmotBaseMoIdC base mo id ( 

Mot_switchCard_id, dn) ; 
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I I i instruct die filter. This code fragment looks for in- 
stances where the values of packetsOul an<l packetsln are 
greater than zero anil the portStatus is "l"P." 

OVmotFilterC filter (Moe__portseatus_id== 1 

// 1 denotes DP 
44 I Mot_packetsOut_id > 0 
I I Mot_packetsIn_id > 0)1; 

6. Construct Uie Managed Object Toolkit GET argument. 

OVmotGetArgC get_arg(base mo id, 

OVMOT NIL/ /Omit Access Control 
OVMOT _CMISSYNC_BEST_EFFORT, 
OVMOT_SCOPE_WHOLE_SOBTREE . 
& filter. 
attr_ids ) ; 

// print to standard output 

cout << "C++ Constructed Get Argument" << 

get_arg << endl ; 

7. Build the XOM CMIS-Get-Argument from the Managed Object 
Toolkit C++ GET argument. 

OM_object xom_object; 

OVmotOXomStrC get_strm (XomWorkspaceP -> 

qWorkspace ( ) ) ; 
get_strm << get_arg; 

xom_object = get_strm.qAdoptXomPrivObj ( ) ; 

8. Issue a standard XMI' get request. 

mp_status = mp_get req( Session, 

MP DEFAULT ^CONTEXT, xom_object, 
tresult, Sinvoke_id); 

Without the Managed Object Toolkit-provided and Managed 
t )bject Toolkit-generated classes the manager developer 
would be faced with the challenge of constructing the X( )M 
CMIS-Get-Request object passed in the mp^geLreql I function, a 
task that could require at least six times as many lines of 
code. 

Summary 

I >e\ elopers who build telecommunications network manage- 
ment applications are implementing large, complex solutions 
ami telecommunication service providers rely on interoper- 
ability standards to integrate and deploy these solutions in a 
heterogeneous networked environment- Developing applica- 
tions that communicate via the standard ('MIS and CMII' 



communication interfaces has historically been an extremely 
complex and time-consuming task using the XMP/XOM APIs. 
The HP Open View Managed Object Toolkit offers the devel- 
oper significant assistance in this task by helping to trans- 
form a GDMO specification into an executable, extensible 
agent application and providing an intuitive C++ interface 
for implementing agent behaviors and manager applications. 
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A Software Toolkit for Developing 
Telecommunications Application 
Components 

To be effective, application developers must understand the data 
available to their applications, the operations required to access the data, 
and the steps required to turn their understanding into an implementation. 
A prototype development environment has been built that helps the 
developer explore and understand the data in the Management 
Information Base (MIB) and construct and deploy pieces of TMN 
management applications. 

by Alasdair D. Cox 



Telecommunications network operators own the largest 
distributed computing systems in the world. Their networks 
cany enormous volumes of i raffle, much of which is highly 
valuable. Maintaining service is essential. The penalties for 
failure are great, and not just financial — emergency services 
and some air traffic control transmissions use the same tele- 
phone network. Not surprisingly, network operators have 
considerable systems and network management needs. 

The ability to provide new services is becoming vital in Ihe 
telecommunications business. Speed and flexibility are key 
requirements, not only of the initial implementation and its 
deployment, but also of the management systems that ensure 
that service continues to operate efficiently. The rapid devel- 
opment of effective management systems is therefore a major 
eoncern, 

The applications that telecommunications companies use to 
manage their equipment, networks, and services they pro- 
vide are known as operations support systems, or < )SS. An 
established network operator will have hundreds of existing 
applications and a continuing need to develop more as their 
systems and technologies change. 

The development of new applications in the Telecommunica- 
tions Management Network' (TMN) area is still carried out 
with the aid of a C or C++ compiler. The developer must 
understand the data that is available to the application, the 
operations that can be performed to reach it. anil the applica- 
tion program interfaces (APIs) and tools available to support 
t hose operations. 

HP Open View products provide support in a number of 
these areas. The GDM< > Modeling Toolset (page -13) helps 
the application developer understand the kind of data that 
is stored in the TMN world. The Open View Distributed Man- 
agement platform (page <>) provides standard APIs that the 
developer can use to send CMIP (Common Management 
Information Protocol) messages to the data. The Managed 
Object Toolkit (page 52) provides further support to the C++ 
programmer. 



In this paper We describe a prototype development environ- 
ment that addresses some of the demands of application 
development in Ihe telecommunications world. This proto- 
type helps Ihe user explore the available management data 
and make enough sense of it so that the user can construct 
and deploy pieces of management applications. 

Background 

The Telecommunications Management Network is an attempt 
to standardize the management of telecommunications net- 
works. It consists of a set of existing and evolving recommen- 
dations from the International Telecommunications Union's 
Telecommunications Standardization Sector, known as the 
ITL'-T- These recommendations are based on a number of 
previous recommendations on Open Systems Interconnection 
(OSI) systems management, now adopted as international 
standards. 11 

The OSI systems management standard proposes a Manage- 
ment Information Base (MIB). 1 which is a collection of data 
necessary for managing a network. This data is organized 
hierarchically and related by containment. The dala is in the 
form of objects, called managed objects, which are defined 
by the Guidelines for Ihe Definition of Managed Objects. 0 

The Guidelines for the Definition of Managed Objects, or 
GDMO. is Ihe language used to define Ihe Structure and some 
of tin- relationships between managed objects. The GDMO 
definition is in Ihe form of templates used to define man- 
aged object classes (classes in standard object -oriented ter- 
minology), attributes (instance variables), actions (methods), 
notifications (events that can be emitted by objects), and 
name bindings, which specify the ways in which objects can 
be related by containment in the MIB. See die article on 
page 43 for more about GDMO. 

The Common Management Information Service (CMIS)' 1 i- 
nsed to interact with the MIB. and Ihe Common Management 
Information Protocol (CMIP) 1 is the way service messages 
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are encoded for transmission between TMX management 
applications and the MIB. 

The available services include getting information from 
managed objects, changing their values, making method 
calls, and creating and deleting managed objects. In addition, 
managed objects can emit events. 

The Development Environment 

We believe dial telecommunication management applications 
of the future will be composed of a number of large-grained 
distributed objects. We call these objects application 
components. Application components differ from managed 
objects in that, at their simplest, managed objects represent 
logical and physical parts of a network. Application compo- 
nents, on the other hand, are pieces of the system that man- 
ages the network and the services naming on the network, 
and they may use. manipulate, and create managed objects 
as they work. 

Some components will be specialized for a particular man- 
agement function wliile others will be of a more general 
nature and may provide services to more than one applica- 
tion. Applications will need access to data in a number of 
sources, including other applications, traditional databases, 
and the MIB. 

We believe that the parts of the application that act as data 
bridges will be split into components, each capable of sup- 
porting transactions to a data source. Since our intention is 
lo support the development of telecommunication manage- 
ment applications, we decided to focus on the construction 
of application components that interact with data, and thus 
we have concentrated on the TMN MIB. 

We have built a prototype development environment that 
includes three tools that operate together to support the de- 
velopment life cycle of application components (see Fig. 1). 



In the initial stages of using the prototype, this means pro- 
viding aid in understanding the problem and progressing 
through to enabling the implementation, testing, and deploy- 
ment of the solution. By taking this approach we believe the 
development process for application components can be 
greatly improved. 

Although the process is likely to be iterative, the basic steps 
in developing an application component using the TMN 
prototype environment shown in Fig. 1 are: 

• Navigation through and exploration of the MIB using the 
MIB browser to build an understanding of the data and the 
way it is used 

• Prototyping CMIS operations using the operation tlefiner. 
which helps to expand or verify the developer's understand- 
ing (The results of executing these operations may be fed 
back into the brow ser to aid navigation.) 

• Storing operations away for future reuse or as documenta- 
tion aids 

• Construction of fragments of application functionality from 
a number of operations using the application component 
editor 

• Deployment of the completed components as distributed 
CORBA* (Common Object Request Broker Architecture) or 
OLE (Object Linking and Embedding) objects or as source 
code for inclusion in libraries or directly into applications. 

The use of a common underlying architectural framew ork is 
a major reason w hy the prototype appears and behaves as 
an integrated development environment rather than as a set 
of standalone tools. This framew ork is discussed later in this 
article. 

• CORBA is tram the Object Management Group (OMG) and OLE is Irom Microsoft • 
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Fi«. 2.( mi put from the MIB 
browser showing a cached subset 
of the managed objects in the MIB. 



MIB Browser 

The MIB Browser provides the user wilh a graphical view of 
the MIB (see Fig. 2). By interacting with and manipulating 
this \iew. the user is able to navigate through the MIB to 
explore the structure and content of the data stored in its 
managed objects. 

The view shown to the user is a cached subset of the man- 
aged objects that exisl in the MIB. The contents of this cache 
are built up as the user navigates through the MIB. A number 
of simple operations are provided for this navigation, each 
causing a C'MIS service request to be sent to the MIB. The 
replies to this request, which can vary from none to veiy 
many, are used to update the cache and hence the view pre- 
sented to the user. 

The browser uses metadata to add meaning to the presenta- 
tion and to help the user navigate. For example, the names 
of managed object classes and attributes and the details of 
attribute values are presented to the user as words, rather 
than as the numbers that the underlying infrastructure uses. 
In addition, the browser is sometimes able to advise the user 
in advance when a navigational Operation is guaranteed to 



find nothing new. This decision is arrived at by using meta- 
data that describes the ways in which the MIB can be orga- 
nized. The design of the MIB browser, including how the 
cache and metadata Tit in. is shown in Fig. 3. 

The MIB browser is useful to application developers and 
operations staff who understand the network and how it is 
managed. It is also useful as an educational aid for training 
the entire staff. Its main benefit is that it is not necessary to 
understand the technical details of a particular area to use 
the browser successfully. In fact, we find that it helps users 
to increase their understanding of the network. 

Navigation by CMIS 

The MIB browser provides five predefined C'MIS operations 
which can be used to retrieve data from the MIB. The user is 
shielded from the execution details of CMIS operations by 
t he user interface. 

Three of the C'MIS operations (expand fully, expand one 
level, and expand by class) are used to discover the struc- 
ture of the MIB. The result of executing (hem is a set of 
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in the MIB. The user seleois a managed object and then 
presses the expand fully button on the browser window. The 
class and ntune of the selected managed object provide I he 
context for the operation. These values are used to fill in the 
base managed objeti class and instance fields of the request. 

Expand One Level. This is a safer < >peratioii than expand fully 
in that it can be used when expand fully would be inappro- 
priate. Rather than discover all the managed objects ltelow 
the selected position in the tree, expand one level discovers 
only those object-s immediately beneath the selected position. 
In MIB-speak, ii finds all the managed objects contained by 
die base object. In computer-speak, il finds the children. 

Expand by Class. In this operation the user is presented with 
a list of those managed object classes tltat could possibly 
have instances below the selected position in the MIB. This 
lisl is computed from the metadata (described below). The 
user can select the managed object classes of interest or 
scan the list and choose likely candidates. Prior knowledge 
is helpful but not essential. The choices are used to parame- 
terize the request. 

All Attributes. This drill-down operation targets a single man- 
aged object that was discovered by an earlier navigation. 
The values of all the object's attributes are obtained. 

Find Class. This operation c;in be invoked on a managed ob- 
ject whose existence and name have been inferred from the 
results of an earlier operation, but whose class is unknown. 

Operation Definer 

The MIB browser provides the user with a small number of 
ways to construct {'MIS service requests. While this is an 
advantage in terms of ease of use. il can appear limiting to 
users with a need lor selective information. To those with a 
greater understanding of the area (i.e., the protocols and 
information models used ) the operation definer gives full 
flexibility in the construction of ( '.MIS requests. < iperalions 
defined this way can be used to extend I he browser's reper- 
toire. The design for the operation definer is shown in Fig. 5. 

As the name implies, the operation definer helps the user 
specify an operation to be performed on the MIB. 1 >nce iis 
specification is completed, the operation can be sent as a 
service request and the corresponding results can be shown 
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managed object names. The MIB brow ser interface presents 
them as nodes on the tree displayed to the user. 

A fourth operation (all attributes) is used to extract I he tie- 
tails of a managed object. These details, or attribute values, 
of the managed object are stored in the browsers cache. 

Finally, the fifth operation (find class) is used to find out 
almui the managed object class of an object whose existence 
has l«?en inferred from the residt of ;m earlier operation but 
altout which we know only the name. 

We decided against making the stnicture-fiiiding operations 
also discover the contents of the managed objects I hey 
encountered, even though this would have reduced the need 
for the fourth operation. There were two reasons for the 
decision: performance and size. Il is not usually possible to 
predict how many responses will be returned from executing 
an operation. For example, a large area of the MIB may he 
w ithin the scope of an operation, possibly containing several 
thousand objects. Since the nature of the underlying ( 'Mil' 
protocol means that each object discovery results in the 
transmission of an asynchronous message to the browser, if 
an operation request ed the contents of each managed object, 
the size of each message would increase greatly and perfor- 
mance would be severely affected. In addition, the user is 
probably not interested in the details of most discovered 
objects. Knowing how they are organized is often what 
matters. So the browser does not need to slore the details of 
every managed object. 

We realized that we could let the user decide which man- 
aged objects had interesting contents, so we provided a set 
of navigational operations and a drill-down" operation, for 
the user to execute appropriately. 

The following sections describe the navigation operations in 
more detail, and Fig. -I shows the values assigned (0 the 
fields in ( 'MIS GET requests for each of the operations, The 
article cm page 52 provides more information about ( MIS 
GET requests. 

Expand Fully This is the crudest navigational operation. Il 
discovers all the managed objects below a specified position 

A drill-dawn operation 15 one tirat enables the user lo see greater detail about a managed 
object 
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to (he user using an operation viewer, which presents infor- 
mation in a way that is similar lo the MIB browser. The user 
can examine the results, and if necessary, modify the opera- 
tion and reissue it. This cycle can continue until the user is 
satisfied with the operation. 

The results obtained by executing an Operation can be added 
to I he MIB browser to expand the view il presents of the 
MIB. hi litis case, the operation defmer can be seen as a 
powerful navigational tool that augments the basic browser. 

Alternatively, the real benefit of the operation defmer might 
be Hie operation itself, rather than the results of executing it 
once. The results returned will be useful because Ihey can 
help prove thai an operation works correctly. The user 
might want to store such an operation so that it can lie used 
again. The operation defmer maintains a repository for this 
purpose. By adding to this repository, the user can build up 
a toolbox of useful operations, similar to the way a system 
administrator builds up a library of shell scripts. 

For an operation to be executable, all aspects of its specifi- 
cation must be fixed. The operation defmer picks up the 
Starting point, which is the base managed object's name and 
class, from the browser context. .Ml oilier aspects of an oper- 
ation are defined by the user. Once this is done, the operation 
can be lested and its definition refined until Ihe user is satis- 
fied with il. If the finished operation is going lo be used again, 
it is likely I hat the user will want it to be made more general- 
purpose. A stored operation can be made more general- 
purpose by specifying that some aspects of it become para- 
meterized, meaning that each lime il is used the values of 
those parameters must be supplied. This allows die effect of 
the operation to be tailored to the contexl in which it is 
applied. In this way, for example, it becomes possible for an 
operation defined on a particular named network element to 
be applied to any network element by supplying Ihe appro- 
priate name and type information. 



Application Component Editor 

As stated earlier, we expect that future telecommunications 
applications will be made up of a number of large-grained, 
distributed objects. We call the objects application compo- 
nents. Some application components will communicate with 
data sources, including Ihe MIB. lo obtain the information 
that other components will use lo perform management 
functions. We decided to concentrate our efforts on support- 
ing the development of application components that interact 
with the MIB. They play a more constrained role dial is better 
suited to automation, and the data they interact wilh is 
described by a standard form of metadata. A window dump 
from the application component editor shown in Fig. 6. 

An application component has four parts: 
« Entity points that make up ihe visible interface of a compo- 
nent ('Other parts of an application make calls to this inter- 
face to use a component.) 

• Operations that inleracl wilh Ihe MIB and issue CMIS 
service requests and receive results 

• Support functions, or scripts, that lie together tile operations 
lo implement the required functionality 

• Test functions, some of w r hieh test individual operations and 
some of which test the whole component. 

As shown in Fig. 7, ihe application component editor uses 
the operation definer's repository. Operations stored in the 
repository can be selected for inclusion in components. 
They are translated into source code and, like a method, will 
perform the same operations when they are executed. The 
fields that are identified as parameters when Ihe operation 
is stored can be treated as formal parameters to the method 
hi addition, simple lest functions are automatically generated 
that test the operation with its original parameter values. 
The results obtained from miming the test function are 
presented to the developer in Ihe same style as the MIB 
browser. 
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Although source code generation is not strictly necessary, 
the ability to generate source code helps make the tools 
acceptable to the traditional telecommunications OSS 
(operations support systems) developer market. 

The component editor is not restricted to editing new and 
existing components, but also provides help in deployment 
There are several ways in which a completed component 
can be made available for inclusion in an application, such 
as: 

• As a CORBA object 

• As an OLE/COM object 



• As a fragment of application source code for direct 
inclusion in larger application programs 

• As a library routine that can be linked into a number of 
applications 

• As part of the implementation of a managed object class's 
run-time behavior. 

We have concentrated on the first option. The signature edi- 
tor shown in Pig, 7 can be used to define formal signatures 
foi entry points, using ASN.l types for the parameters and 
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results. This information is then available io the IDL (Inter- 
face Definition Language) generator which produces equiva- 
lent COKBA IDL interfaces using a standard translation 
algorithm.* 1 ' These inlerfaces help the developer towards 
deployment of application components as CORBA objects. 
A similar process would enable Iheir distribution as OLE 
objects. 

The prototype application component editor generates Small 
talk source code. In fact, We used IIP Distributed Smalltalk" 1 
lo automate the entire process of deploying application 
components as CORBA objects. Although Smalltalk is in- 
creasingly being used for product development, it is usually 

restricted to research and prototyping work. A fully fledged 

tool would have to generate (' or C++. 
Architectural Framework 

Fig. 8 shows the architectural framework upon which the 
three prototype tools (the MIU browser, the operation de- 
rmer. and the application component editor) are built. By 
building on top of this I'ramcwork we were able to increase 
commonality in implementation, appearance, and behavior 
among the tools. 

Graphical Presentation 

All the prototypes were implemented in VisualVVorks Small- 
talk, which meant we were able to use its interface con- 
struction tools lo develop the dialog boxes, menus, lists, and 
buttons that make up most of the tools" inlerfaces. In addi- 
tion, because Smalltalk is an object-oriented language, we 
could subclass interfaces and specialize them for particular 
tasks. For example. I here are several browser-type interfaces 
used by all three tools in different ways. These were not 
implemented independently Instead, we implemented the 
common features in a superclass, which was inherited from 
the supplied VisualWorks classes, and created subclasses 
that became the browser and viewers for displaying the 
results of operations and test functions. In this way the 
three tools share a common look and feel because much of 
the code is common to them all. Fig. 9 shows the inheritance 
hierarchy. 

The managed objects in the MIB are organized into a tree 
called a conlaiitiimit Irrc because the trees edges repre- 
sent a containment relationship. This reflects the equipment- 
oriented origins of the OS1 systems management standards. 
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Fig. 9. Inheritance hierarchy of the graphical presentation ctesse* 

For example, networks contain equipment such as multi- 
plexers, which contain circuit boards which in turn contain 
software. The MIB browser enables users to navigate 
through the containment tree. It seemed natural to present a 
view of the discovered containment tree and allow I he user 
lo interact with il via buttons and menu selections. These 
operations cause the browser lo execute CMIS operations lo 
extend the browser in the way the user directs. The browser 
shows a view of the tree as it is discovered during a bn iwsing 
session. We fell lhal users would noi see lite larger picl tire if 
they focused only on one managed object at a lime or were 
presented wilh only a view of the path through the tree to 
thai object. This larger picture Often provides the context 
that helps the user understand the smaller picture. 

One lesson we learned front Ibis prototyping experience is 
thai more flexibility is necessary when presenting informa- 
tion to the user. It is possible to discover quickly many hun- 
dreds or thousands of managed objects using the browser. 
This is generally more than the user wants lo deal wilh. 
Currently we advise Hie user to retrace steps and try again, 
applying more constraints to the search. In the future we will 
help the user with ways lo reduce the clutter on the screen 
rather than put the responsibility on the user to figure out 
how to reduce it. 

Metadata Services 

Many different types of metadata are used by the tools that 
make up the MIB browser, including: 

• GDMO. which describes the kinds of data that can be stored 
in the MIB and how it can be Structured 

• ASN.l, which describes the basic data types that can be 
stored 

• IDL. which the application component editor generates 
from the Signature of the components' external entry points 

• Descriptions of how an operation should be parameterized 

• Descriptions of each application component 

The tools obtain the GDMO mid ASN.l metadata via the HP 
OpenView metadata services. The metadata is stored in a 
repository and can be queried by all of the tools. Some 

adtied services are implemented. For example, when the 

user wants lo find objects of a particular class or classes 
that are below a selected object in the MIB. the allPossibleSub- 
ordinateClasses service provides a list of the classes that it 
makes sense to allow the user to select from. This list is 
often much shorter than the lisi of all known managed 
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object classes, making it quicker and easier to perform tin- 
action. 

The CMIS requests and confirmations that flow between Hie 
browser and the MIR use ihr CMIP protocol Tlie information 
passed in the messages is numeric. For example, while the 
user wants tp refer to the network class, the downstreamConnec- 
trvityPotnter attribute, ;uid theiniernalTimingSource. speech, locked, 
anil Sunday data values, the < M1P protocol will expect to see 
ihe numerical values | n (i 13 3100 0311(0 o 13 3100 o 7 1» ], 
0, (1, 0. and 0. Our metadata services perform these context- 
sensitive translations automatically in both directions. 

The MIB Cache 

lite MIB cache contains a subset of die managed objects con- 
tained in the MIB. This subset is built up in the cache as the 
user navigates through the MIB while using the MIB browser. 
Operations used to handle this navigation result in responses 
being sent from the MIB. A response equates to a single 
managed object involved in the operation. Sonic responses 
indicate errors and others return data. Each data-bearing 
response contains the name and class of the responding 
managed object and possibly some additional data, such as 
the values of attributes. 

The tools parse the results and store the values in the MIB 
cache. This reflects what has been learned about the MIB by 
die tools. The cache can be preloaded (seeded I on startup, 
which allows the browser to provide an initial context. 
When the MIB browser or similar viewers present a picture 
Of the MIB. they are really presenting views of information 
in the MIB cache. 

cmis Services 

The ( MIS sen ices enable the tools to issue multiple synchro 

s ui asynchronous < MIS requests and receive multiple 

responses to each request. We built these services on Small- 
talk's support for multiple thread execution and synchro- 
nization. 

Smalltalk classes that represent ( 'MIS requests and confir- 
mations were denned. A request object can be submitted to 
the i MIS sen ices component, causing the operation that it 
represents to be executed, a number of confirmations will 
later be received and a confirmation object will be created 

tor each conflnnationi These confiniiations are then sent to 

the Smalltalk process that made the request 

HP OpenVievv Distributed Management Platform 

The tOOtS Connect to aft intermediary program called the 
( MIS interpreter, which in turn uses the lift IpenView 
Distribution Managnienl Platform as the distribution mecha- 
nism and communications provider. The ( MIS interpreter 
uses Open View's standard \t IM/XMP APIs to generate, 
send, receive, and parse CMIS requests and con fin nations. 
( 'omnuillicalion between the tools and the ( 'MIS interpreter 
is via mi ASCII language, which is like a symbolic 1'onn of 
(MIS. 

This arrangement provides us with the power of a symbolic, 
object -oriented language Tor rapid development while still 
enabling us to make use of the communication facilities of 
the IIPOpeiiY'iew DM platform, which is designed to work 
With ( and (' • t clients. 



ASN.l Representation 

The representation of ASN. 1 types and values is important 
to all the major architectural com p onents. Values are passed 
to and from the CMIS services, stored in the MIB cache and 
displayed by the graphical presentation comjMineni. ASN.l 
types arc stored in the metadata's repository described 
above. 

Conclusion 

We have described the prototype of a soft wan- environment 
that aids the construction of telecommunications management 
applications. It is made up of three tools that together ad- 
dress many aspects of the development life cycle, from in- 
vestigation of the problem to the deployment of the solution. 

In choosing to address application components that interact 
with the TMN MIB. we deliberately focused on a well-defined 
subset of the overall application development area. We were 
then able to build tools that partially automate the task. We 
believe this automation could greatly increase developer 
productivity. The tools' usefulness is not restricted to Ihe 
development of applications. The MIB browser, combined 
with the operations and components buill using the other 
tools, is a powerful environment for exploring, understand- 
big, and troubleshooting the MIB. 
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Business Process Flow Management 
and its Application in the 
Telecommunications Management 
Network 



HP OpenPM is an open, enterprise-capable, object-oriented business 
process flow management system that manages business activities 
supporting complex enterprise processes in a distributed heterogeneous 
computing environment. It is a middleware service that represents a 
substantial evolution from traditional workflow technologies. 

by Ming-Chien Shan, James W. Davis, Weimin Du, and Qiining Chen 



Business process reengineering is emerging as one ofthe 
crucial business strategies of the 1990s, Business process 
reengineering is the fuiidamenlal rethinking and reimple- 
nientalion of business processes to achieve ncver-before- 
possible levels of quality, cost, throughput, and service. This 
is especially significant in an era of workforce downsizing 
and greater demands for shortened lime to market and faster 
customer response. The need for business process reengi- 
neering is pervasive. Organizations are currently engaging in 
business process reengineering in many domains, including 
financial services, telecom services, healthcare services, 
customer order fulfillment, manufacturing procedure auto- 
mation, and electronic commerce. 

While business process reengineering provides a business 
management concept, business process How management 
(BPFM) software — or more accurately, middleware — pro- 
vides the enabling technologies for business process reengi- 
neering to support flexible solutions for the management of 
eQterpijse-Wide operations, including: 

> Process How control, automation, and monitoring 

' Resource allocation, authorization, and authentication 

1 Task initialization anil data exchange 

i End-to-end communication and security. 

BPFM is more than just a technology. It offers an overall 
environment and approach to unifying, automating, and 
measuring business processes. In addition, BI'FM is not a 
technology supporting only business process reengineering. 
It can be used to manage existing nonautomateel legacy 
processes — what is often called "paving the cow paths." 

Business Process Flow Management System 

At the enterprise level, the process to he managed can be 
very complex, spanning sev eral organizations with multiple 
steps being performed in parallel. In such cases, a BPFM 
system can act as the superstructure that ties together dis- 
parate systems whose business purposes are interconnected. 

A BPFM system provides procedural automation of a busi- 
ness process by managing the sequence of process activities 



and the invocation of appropriate human, instrument, or 
computer resources assoc iated with various activity steps. 
It involves the high-level specification of Hows, and provides 
the operational glue and environment support for managing 
and automating the Hows, recovering from failures, and en- 
forcing consistency. A BPFM system also enforces various 
administrative policies associated with resources and work. 

The structure and How of a business process managed by a 
BPFM system can be preplanned or ad hoc. In t he case of a 
BPFM system managing the process of providing telecom- 
munications service, the flow of the process is ad hoc and 
depends on the services required by a customer. However, 
rei lain aspects ofthe process will be preplanned and delib- 
erately structured. For instance, regardless of the individual 
services required by a customer, the process always origi- 
nates in the sales department and is always ends in the billing 
department. 

Typically, a BPFM system: 

• Provides a method for defining and managing the How of a 
business process. 

• Supports the delinit ion of resources and their at tributes. 

• Assigns resources to work. 

• Deternuites which next steps will be executed w ithin a 
business process anil when they will be executed. 

• Ensures that the business process flow continues until 
proper termination. 

• Notifies resources about pending work. 

• Enforces administrative policies such as access control. 

• Tracks execution and supports user inquiry of status. 

• Provides history information in the form of an audit trail for 
completed business processes. 

• Collects statistical data for process and resource bottle- 
neck analysis, How optimization, and automatic workload 
balancing. 

HP OpenPM 

HP OpenPM is an open, enterprise-capable, object-orienu -d 
BPFM system developed at HP Laboratories to manage 
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business activities supporting complex enterprise processes 
in a distributed heterogeneous computing environment. It is 
a middleware service that represents a sulistantial evolution 
from traditional workflow technologies. 

Given the trend towards open systems and standards, a 
BPFM system must coexist with and take advantage of stan- 
dards-based commercial products for network communica- 
tion, legacy application invocation, and system monitoring. 
In particular, the OMG's CORBA (die Object Management 
Group's Common Object Request Broker Architecture), the 
OSPs DCE I the < >pen Software Foimdation's I iistnl'iiied 
Computing Environment). IIP Open View, and [SO OS! 
( International Standards Organization Open Systems Inter- 
connection) X.400 technologies are expected to play ;ui 
important role in the development of BPFM systems. IIP 
OpenPM provides a generic- framework and a complete set 
of services for business proc ess flow management using I he 
above-mentioned standard technologies, with emphasis on 
performance, availability, scalability, and system robustness. 

Basically, HP < >pcnPM provides: 

An open system adhering to the CORBA comniunicalions 
infrastructure and providing a WfMC (Workflow Manage- 
ment Coalition) Standard interface. 

High performance as a result of optimized dalahase access 
and commitment. 

Effective management with an BP < (pen View-based system 
management environment. 

A comprehensive solution for business reengincering 
including an extensive set of products. 



The overall archil ecture of an HP < )penPM syst em is de- 
picted in Fig 1 The core is the HPO|ienPM engine, w hich 
supports five interfaces for business proc ess definition, 
business process execution, business process monitoring, 
resource and policy management, and business object 
management. 

A business process is specified via the process definition 
interface. An instance of the- business process can be 
started, slopped, or controlled via the process execution 
interface. Status information of each process instance and 
load information of the entire system can be queried via the 
process monitoring interface. The resource and policy man- 
agement interface is used to allocate, at run time, execution 
resources to a task, according to the policies defined by the 
organization (including authorization and authentication) 
and the availability of the resourc es. Interaction with the 
external world (e.g.. the invocation of an application, the 
control of an instrument, or the delivery of a work order to 
a person's e-mail intray ) is the task of the business object 
management interlace. 

HP OpenPM Process Model 

A business process is a description of the sequencing, tim- 
ing, dependency, data, physical agent allocation, business 
rule and organization policy enforcement requirements of 
business ac tivities needed to enact work. 

An IIP OpenPM process is a directed graph consisting of a 
set of nodes connected by arcs. Fig. 2 shows an example of 
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the user interface. There are Iwo kinds of nodes — irork nodes 
and rule ihiiIp.s — and Iwo kinds of arcs— forward arcs and 
reset hits. A work node lias al most one inward arc and one 
or more outward arcs. A rule node can have any number of 
inward and outward arcs. 

Work nodes represent activities to be performed external lo 
llie IIP OpenPM engine. These aclivilies include authoriza- 
tion, resource allocation, the execution of business objects, 
and die provision of input data for Ihe business objects and 
output data from them. Rule nodes represent processing 
internal to the HP OpenPM engine. This processing includes 
decisions of what nodes should execute next, the generation 
or reception of events, and simple data manipulation. 

A work node is a place holder for a process activity, which 
is a logical representation of a piece of work contributing 
towards the accomplishment of a process. A process activity 
is mapped lo the invocation of an operation on business 
objects during Ihe execution Of the process. Each process 
activity can represent a manual operation by a human or a 
computerizable task to execute legacy applications, access 
databases, control insinunentation. sense events in the 
external world, or even effect physical changes. A process 
activity definition includes aforirard activity and optionally. 



a compensation activity, a cancel activity, a resource man- 
agement activity, timeout and deadline informal ion, and 
inpul and Output data. 

Rule nodes are used to specify process Hows thai are more 
complex than a simple sequence. A rule language is used to 
program Ihe ride node decision. When executed, a rule node 
del ermines which outward arcs to lire, based on Ihe status 
passed along Ihe inward arcs, the time al which each inward 
arc is Bred, mid the proeess-relevanl data associated wilh 
the process instance. 

Rule nodes are also used to support events. A rule node can 
raise events when certain conditions are met as defined by 
Ihe rules, and an event can activate rule nodes Ihal have 
subscribed to receive the eveni. 

Forward arcs represent Ihe normal execution How of process 
activities and form a directed acyclic graph. Successful com- 
pletion of a node at the source end of a forward arc triggers 
Ihe starting of the node at the destination end of the forward 
arc. 

Reset arcs ar e used lo support repetitions or explore alter- 
natives in a business process. Reset arcs differ from forward 
arcs in that they reach backwards in the process graph. 
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Rule nodes are exec uted each time any inward arc fires. 
Work nodes have states of initial or fired. When the inward art- 
is fired on a work node in the initial state, the work node 
changes its state to fired and performs its associated activity. 
When the inward arc is fired on a work node in the fired 
stale, nothing is done. 

A reset arc, together with the forward arcs between its des- 
tination and source, forms a loop. When traversed, a reset 
arc causes all nodes within its loop to be reset. Resetting a 
fired work node changes its state to initial so that the node 
can be reexecuted. Resetting an active work node cancels 
the current execution of the corresponding process activity 
and change its state to initial. 

.Associated with each business process, there is a pivress 
(lain template defined by the business process designer. The 
process data template is used by users to provide initial data 
for the creation of process instances. At run time, based on 
the process data template and read/write lists of activities 
defined in a business process. HP OpenPM will generate a 
COM pocket for each process instance to facilitate data pass- 
ing between activities and the IIP OpenPM engine- 
HP OpenPM Process Execution 

Fig. 3 shows a simplified version of the component structure 
of the IIP OpenPM engine, which coordinates the overall 



execution flow of business processes. It fiuictions as a highly 
reliable, log-based state machine. The HP OpenPM engine 
interfaces wit h external environments through a uniform 
CORBA-based transport interface, independent of the actual 
physical dispatch of the requests. 

The HP OpenPM engine launches business process instances 
in response to user requests. For each instance, the HP 
OpenPM engine steps through the nodes according to Un- 
order specified in its business process definition. For work 
nodes, the HP OpenPM engine will execute the associated 
process (forward) activity. For rule nodes, the HP OpenPM 
engine will evaluate the rules and perform the rule actions 
when the rule conditions are met. 

Each node transition is durably logged to facilitate forward 
rolling of incompleted business processes at system restart 
time in the event of a system failure, or to facilitate a sup- 
port activity compensation process in the case of a business 
activity failure. In addition, HP OpenPM allows flexible 
specification of compensation scopes and actions (e.g., 
compensation activity or cancel activity) to support various 
application needs. 

In HP ( (penPM, different versions of similar business pro- 
cesses are supported by the engine under the concept of a 
process group. The user can designate a particular version 
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as the default to lie used when no specific version is re- 
(|iicsie(l al (he lime a business process instance is created. 

To monilor the progress of running business activities and 
support system nianagenient. the HPOpenPM engine niain- 
lains a comprehensive log of all events and prov ides a native 
interface as well as SNMP/CMIP gateways to facilitate inte- 
gration with the HP Open View environment. The formats 
and contents of the logged information can he customized to 
support specific application needs. 

HI' OpenPM Business Objects 

IIP < ipcnPM lias to interact with business activ ities sup- 
polled by various implementations encountered in real life. 
These can range from manual handling by humans to auto- 
mated processes executed by computers. An infrastructure 
is Deeded to enable the effective management and invoca- 
tion of these business activities. 

Distributed object technologies have become the primary 
infrastructure for enterprise-scale distributed computing. 
Among them, the 0M0 (Object Management Group) CORBA 
(Common Object Request Broker Architecture) technology 
has been developed to support interoperability for applica- 
tion integration. 

Based on CORBA technology, in HPOpenPM an abstraction 
called a business object is built to encapsulate whatever 
piece of work each process activity has lo accomplish. 
The wrapping code provides an IDL (Interface Definition 
Language) interface and the business objects are catalogued 
in the HPOpenPM business object library. 

A business object, as defined by the OMG, is a representation 
of something active in the business domain, including its 
business name and definition, attributes, behavior, and con- 
straints. It provides a uniform way to encapsulate legacy 
systems and applications, anil a direct mapping, in under- 
standable business terms, between the business model and 
the possibly sophisticated operational procedures of the 
business process system. 

By representing these process activities in business objecls, 
new business processes can be quickly created by assem- 
bling business objects to describe business processes. The 



business object library avoids repetitive coding lo tailor the 
business activity implementation lo each individual business 
process. 

HP OpenPM Resource and Policy Management 

A resource is a person, computer process, or machine that 
can be used to accomplish a lask. A resource has a name 
and various attribules defining its characteristics, such as 
job code, skill set, organization unit, and availability. 

A in/lit 1/ is a set of rules thai determines how resources are 
related to tasks within a BPF.VI syslem. ( me common use is 
for task assignment. Policies can be used to specify which 
resource, under which role, is eligible or available to per- 
form a lask. Policies are also used lo ensure proper autho- 
rization and authentication. 

In IIP ( IpcnPM, the mapping between the business activity 
((ask) specified in a business process and (he business object 
(resource) lo be invoked is performed by the resource man- 
ager during run time as part of the execution of the business 
activity. IIP OpenPM allows multiple resource managers lo 
be used to resolve a single resource assignment request; 
each resolves the request at a different level within an orga- 
nization. 

HP OpenPM Worklist and Application Data Handlers 

Two optional components that can be added into the IIP 
OpenPM environment lo facilitate the execution of business 
processes are the worklist handler and the application <i<ii<i 
handler (Bee Fig. 1). Both components are designed to en- 
hance the scalability of HP OpenPM systems. 

The worklist handler supports both fiighir-push and rlinil- 
/>(/// modes to provide more freedom in task assignment. 
In addition, the worklist handler can be used lo support the 
concept of integration on demand. Based on the task 
performer's profile, the worklist handler determines and 
launches a specific environment for an activity at run lime, 
rather Ulan hard-wiring il into the process definitions. 

The application data handler supports the separation of 
application-specific data and process-relevant daia (o reduce 
the amount of data flow over the network. Il also provides 
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the preparation facility for application-specific data to 
remove the burden of database access from activity per- 
formers. 
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HP OpenPM Security 

In today's business environments, security must be imple- 
mented enterprise-wide. The security service developed by 
the OMG provides authentication and encryption for HP 
OpenPM to prevent eavesdropping and forgery. The HP 
OpenPM infrastructure components can identify each other 
and vouch for the credentials of end-user components. 

BPFM in the Telecommunications Management 
Network 

The Telecommuiiications Management Network (TMN) 
defined by the International Telecommunications L'nion is 
changing the way operations support systems and business 
support systems solutions are being developed. The TMN 
architecture separates layers of functionality and provides 
access by elements in any one layer to any element in the 
layer immediately below. Before the introduction of the 
TMN model, operations support systems and business sup- 
port systems solutions were isolated from each other and 
could not interoperate. 

The HP Open View Distributed Management platform sup- 
ports the realization of TMN operations support systems and 
business support systems solutions for the TMN element 
management layer and network management layer (see the 
article on page fi for a description of the TMN layers). Still 
needed is a middleware service supporting the service man- 
agement layer and even the business management layer of 
the TMN model. This need offers a great opportunity for 
BPFM added value. The next section presents an example of 
this support. 

At the service management layer, the BPFM process enabling 

framework is required to be able to: 

Support reengineering and transformation processes for 

strategic operations support systems and business support 

systems. 

Integrate existing operational environments to form an 
enterprise huh for service management and provisioning. 
Deploy new management services as rapidly as possible. 
Monitor and measure processes. 
Time processes to benefit from experience. 
Automate processes to reduce execution time. 

The overall deployment of BPFM technology in the TMN 
environment is depicted in Fig. 5. 

SONET Configuration Management Prototype 

Based on an IIP • ipenPM system, we built a prototype to 
demonstrate the application of BPFM technology in the 
specific domain of S( )NET I .Synchronous ( iptical Network) 
configuration management. The prototype was ajoint proj- 
ect between IIP Laboratories in Bristol. England and Palo 
Alto, California to demonstrate the middleware technologies 
required to automate the processes supporting the configura- 
tion management of a SONET telecommunications network. 

The scenario demonstrated by this prototype consists of the 
provision of a new VC4/VC12 path for customers. It goes 
lhrous>h several different steps lor this operation: search for 
a new route, negotiate the service level agreement (SLA) 
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Fig. 5. Ti'lpr rpmniiitiirntions Management Network layers, 
showing management functions provided hy business process 
flow management 

with the customer, configure the new path, and finally, up- 
date the SLA for this customer. The IIP OpenPM process 
definition supporting the process of providing this new 
SONET data path is sketched in Fig. 6. 

Searching for and configuring a new path in SONET are 
complex processes requiring a lot of interaction with the 
S( >NET MIB i Management Information Base) and network 
elements. This type of operation is a source of errors when 
it Ls performed manually by an operator as a set of individual, 
uncorrelated activities. 

In the prototype, such complex operations as searching and 
configuring new paths are handled as business processes 
and automated by an HP OpenPM engine in an environment 
interacting with HP Open View DM and < trade DBMS appli- 
cations. 

Depending upon the changing business needs, a customer 
can request to add or drop communication paths between 
certain endpoints in a private virtual network (PVN). In HP 
OpenPM. these sen ices can be modeled as business pro- 
cesses to be exec uted by the service provider. Adding a new 
path may consist of the following activities and decision 
points: 

1. Retrieve the customer's profile from the customer data- 
base for customer-PVN-specific information. 

2. Locate the closest acid-drop multiplexers tADMs) to the 
endpoints. based on the information stored in the SONET 
physical configuration database. 

3. Check whether fiber connections exist between the end- 
points and the two end-ADMs. 

4. If not, issue a request for an engineer to go onsite and 
physically connect the endpoints to the end-ADMs. After the 
establishment of the connection, the process continues on 
lo step "i and an independent subprocess is initiated to watch 
for resource changes. 

">. Find valid routes between end-ADMs. This requires access 
to the routing table in the S1.A database to determine whether 
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iuiy valid routes exist between the two end- ADMs. Either a 
list of ADMs is returned signifying the ADMs thai must be 
configured 10 realize (lie route, or "No Route Found" is re- 
turned. For a returned list of ADMs. this activity will then 
use the IIP Open View I >M facility agent to collect port infor- 
mation stored in the MIB to determine the available ports 
between the ADMs that are iibered together and can be used 
to enable (he path. 

(i. Check network element (NE) capabilities. For an ADM in 
the route, tills activily uses the IIP OpenV'iew D.M NE agent 
lo access the MIB in formal ion to determine whether a VC4 
cross-connection can be set up in the ADM between the 
selected pons of the ADM, This activity has to be execuied 
for each ADM in the route. During st eps 5 and G, if any addi- 
tional resources become available, HI' OpenPM cancels any 
currenlly running activity and starts the process over from 
step 5 to consider these newly available resources. 

7. Get customer's approval of the select ed configuration. 
Once a suitable path is identified, the customer will review 
the offer, including available date, charges, quality of services 
(QoS), and so on. Depending upon I lie business factors ( e.g.. 
cheapest sei-vice wanted), the customer may request that a 
new search be Initiated, lhat is. loop back to step 5 to find 
another valid route. 

8. Configure the selected route. This activity is responsible 
for setting up the cross-connections in each ADM by invok- 
ing the HP Open View DM NE agent and updating the SLA 
database. 
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HP OpenView Agent Tester Toolkit 

In developing HP OpenView agents, a major challenge is to develop and 
test both the agent and the manager simultaneously To fill this need, the 
HP OpenView Agent Tester Toolkit generates tests and allows the 
developer to execute these tests individually or as a set- 
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IIP OpenView agents can be created by telecommunications 
network management developers either by using tools or by 
writing the code directly. The tools available include the 
QDMO* Model imj Toolset (see page l-'i), which helps in the 
design and specification of network management objects 
using the (il)MO language, and the UP MaiMi/rd Object 
Toolkit I see page 52), which accepts GDM( > documents and 
produces C+ + code to implement a default agent that meets 
those specifications. Whether the developer builds an agenl 
using these tools or writes the code by hand, one of the major 
challenges is lo develop and lest both ends of the commu- 
nications link simultaneously — the <igcnt controlling the 
managed device and the mintage) 4 that sends requests to the 
agent and receives the responses. To fill this need, the new 
UP OpenView Agent Tester Toolkit generates tests and 
allows the developer lo execute these tests individually or 
as a sel. 

The Role of an Agent 

An agent program enables other programs, called managers, 
to control physical and logical resources. Examples of re- 
sources that are controlled by agents are telephone switching 
equipment and phone sen ice databases. From a centralized 
location, a telephone service prouder can use automated 
processes lo monitor the performance of the communica- 
tions lines, reroute traffic as necessary, and maintain the 
business and accounting records. Because the communica- 
tion protocol between managers and agents has been stan- 
dardized, a wide area network of mullivendot equipment 
can be efficiently Controlled from a small number of central 
locations. 

The resources being monitored and controlled are modeled 
as objects called intmtiged object classes. Managed object 
classes are logical groupings of the attributes, events, and 
actions associated with a resource. A (llt.M* I specification 
defines the various managed object classes thai make up 
I he interface to the resource. Instances of these classes are 
called into existence by sending a creale request. The attri- 
bute values for an instance are accessed by issuing sel and 
gel requests tO Change OI retrieve the attribute values, re- 
spectively. I Mher message types remove an object instance, 
allow thO agenl lo notify interested parties of an asynchro- 
nous change, or cause the agent to perforin some agreed- 
upon activity. 

* til IU0 is the ISO (International Standards Otgani/ationI Guidelines lor the Dulmition ol 
Managed Otj/ects 



A collection of managed object instances and their relation- 
ships is called the containment tixv. Subobjects are logically 
contained or grouped within other objects. Fig. 1 depicts a 
portion of a containment tree. Each of the boxes in Fig. 1 
represents ;m object instance. The label in each box identi- 
fies the object class of thai instance. For example, in Fig. I, 
B fiber-optic network is composed of two network elements. 
In one of those network elements, the regenerator and multi- 
plexer sections are shown. 

One of the attributes within each of the contained Object 
instances is designated as the distinguishing attribute, and 
the value of this attribute is used to uniquely distinguish that 
instance from all of its siblings. The commitment Iree is 
used tO uniquely identify, or mime. ;ui object instance. An 
object instance anywhere in the containment tree is identified 
by specifying the distinguishing attribute and its value from 
the top of the tree down to the desired instance. The con- 
catenation of all of the distinguishing attributes along t his 
naming path is called thefilUy distinguished mime. In Fig. 1. 
the fully distinguished name for the multiplexer section 
would consist of the sequence networkld - "netl". elementld = 5; 
muxld = 56. 
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Agent Development 

The Managed Object Toolkit saves an enormous amount of 
work by handling all of the overhead of decoding and vali- 
dating incoming requests, locating the selected object in- 
stance within the containment tree, and invoking an appro- 
priate C++ method on the selected object. However, the 
attribute values that are set or retrieved by the initial Man- 
aged Object Toolkit output are only internal representations. 
The developer is responsible for filling in empty C++ stubs 
to make the internal attribute values reflect the state of 
external physical devices. During this coding process, it is 
helpful to simulate the requests that will eventually be sent 
by a manager. 

The Agent Tester Toolkit performs this task in two steps. 
First, it creates test requests from the GDMO specification. 
Second, it transmits these requests over the network to the 
agent and receives the responses. During the development 
phase, these test files can be sent individually and the re- 
sponses viewed interactively. As each agent operation is 
implemented, the associated test requests can be added to a 
test suite. The accumulated tests can then be run in a batch 
mode to check that previously implemented functionality 
still works properly. r'ig. 2 depicts the sequence of steps 
needed to generate and send the test requests, and shows 
how the Agent Tester Toolkit relates to other development 
tools. 

Running the Agent Tester 

The components of the Agent Tester Toolkit arc command- 
line tools that are invoked in a straightforward way. For 
example, ovatgen -t /tests gdmo.mib reads the GDMO description 
in the file gdmo.mib and generates a set of test requests stored 
in files under the directory /tests. Next, tests for a particular 
object instance can be sent to the agent as follows: 

S ovatrun -i 
>create 

>getall 

>mytest 

>delete 

The -i option to ovatrun specifies the interactive mode, in 
which the user can type the name of a test file in response to 
the > prompt and the response from the agent is displayed 
immediately ( shown by the dots above). 

The test files represent CMIS (Common Management Infor- 
mation Service. ISO/IEC 9595) operations, such as create, 
set, get, and so on, and are stored in a directory layout that 



mirrors the organization of the agent's containment tree, 
with each directory named by its associated managed object 
class name. At each level in the containment tree, test files 
are generated that create an object instance, get all attributes, 
and delete the instance. If there are changeable attributes, 
tests are also generated that set those attributes to new 
values and retrieve the changed attributes. In addition, files 
are generated that test attribute groups and actions. Docu- 
mentation files describe the object identifiers used in the 
tests anil optional features called coiiililiomil packages. 

Each test request is written in a format called ASN. 1 value 
notation, which is a standardized format described in ISO 
and ITl'-T documents (8824 and X.208, respectively). ASN.l 
( Abstract Syntax Notation One) is a notation for expressing 
i he ivpes of the attributes and operations. For example, a 
test file that contains a get request to retrieve the current 
values of several attributes might appear as: 

GetArgument { 

— passwordEntryManagedObjectClasa 
baseManagedObjectClass {1 3 6 1 4 1 11 9 81), 
baseManagedOb j ectlnstance distinguishedName : 

{ 

{ 

{ 

— passwordRootName 

attributeType {1 3 6 1 4 1 11 9 29) , 
attributeValue Mod . RootSyntax 0 

} 

). 
{ 

( 

— loginName 

attributeType {1 3 6 1 4 1 11 9 21), 
attributeValue Mod . LoginSyntax "paul" 

} 

) 

), 

attributeldList { 
-- password 
{1 3 6 1 4 1 11 9 22), 
— userlD 

{1 3 6 1 4 1 11 9 23) 

) 

) 

In this example, the first word, GetArgument. announces the 
ASN.l type whose value follows. A GetArgument is a struc- 
tured type, and in this example its fields are baseManagedOb- 
jectClass. baseManagedObjectlnstance, ami attribute-ldList. Lines 
beginning with — are comments insetted by the Agent Tester 
Toolkit generator to help the reader identify the various 
object identifiers (OIDs ). which are strings of digits (e.g., 
{1 3 6 1 4 1 1 1 9 23)) that uniquely identify attributes, classes, and 
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other fields. Returning to ihe GetArgument request, when sent 
by the Agent Tester Toolkit it asks the agent to return the 
current value of the password and user ID attributes of an 
object of class passwordEntryManagedObiectClass. The particular 
instance is identified by an object instance passwordRootName 
= 0. which in turn contains the desired subobject loginName = 
paul. A typical response would be: 

GetResult ( 

managedObjectClass {136141 11 9 81). 
managedObject Instance distinguishedName : ( 
f 

{ 

attribuceType {1 3 6 1 4 1 11 9 29), 
attributeValue Mod. Root Syntax 0 

) 

), 
t 

( 

attributeType {136141 11 9 21), 
attributeValue Mod . LoginSyntax "paul" 

) 

) 

), 

currentTime "19960327145135", 
attributeList { 
{ 

attributeld { 1 3 6 1 4 1 11 9 22) , 
attributeValue Mod . PasswordSyntax "secret" 

t 

attributeld {136141 11 9 23), 
attributeValue Mod. User IDSyntax 4463 

) 

} 

} 

This response returns the requested class and instance infor- 
mation, anil reports that the values of Ihe two requested at- 
tributes password and userlD were secret and 4463. respectively. 

It is also useful to gather as much informal ion as possible 
when error conditions exist For example, if we try Eo query 
an object that doeshl exist, an error is returned, letting us 
know what aspect of the request was rejected: 

$ ovatrun -i 
>getbad 

-- Error: No such object instance 
Objectlnstance distinguishedName : { 
( 

{ 

attributeType {136141 11 9 29), 
attributeValue Mod. RootSyntax 0 

) 

>. 
{ 

{ 

attributeType (136141 11 9 21), 
attributeValue Mod . LoginSyntax "joe" 

) 

1 

) 

Test files are ordinary text files, and customized tests can be 
crafted using Ihe generated tests as guides. Several support- 
ing tools are included ill the Agent Tester Toolkit. 



Batch Testing 

After |>ortions of the agent have been developed and the 
tests an- working individually, it is good practice to run the 
tests and check the results in an automated fashion This is 
useful to monitor existing behavior of an agent as new- code 
is added, or to be able to repeat the testing process as new 
versions of the agent are developed or die agent is ported to 
new hardware platforms. To this end, the Agent Tester Tool- 
kits nui program can execute a sequence of tests In succes- 
sion. Tile command is ovatrun without the -i option: 

$ cd /tests 
$ ovatrun 

This causes the list of tests in a default tesr director file, 
batchjist, to be run and the responses stored. After all tests 
have been run, the responses are compared against a set of 
known-good results, and summary statistics are prepared in 
a log file, reporting the number of tests run. passed, and 
failed. The known-good result files are generally prepared 
by copying actual response files that have been manually 
verified. A utility tool is provided that copies result files into 
place as known-good comparison files. As part of the copying 
process, this utility removes lines that contain the current 
time, since Uiis would needlessly cause c omparison failures 
in future test suite runs. 

The test director file in its simplest form contains the names 
of the lest files and the order in which they are to be sent. 
Optional commands in this file allow for more complex situ- 
ations. For example. ISO Standard L0164-1 identifies situa- 
tions (object creation, object deletion, and attribute value 
change) in which the agent should emit an event so that all 
interested managers can maintain a synchronized view of 
the agent's state. To alert the Agent Tester Toolkit to expect 
both a response I" one of its own create, delete, or set re- 
quests ;uid Ihe resulting event emitted by the agent. Ihe pair 
command can be used. For example, the command pair pass- 
word/create semis the request command contained in the file 
password/create and then receives both Ihe continual ion of 
Ihe request and a notification that the creation has occurred. 
Similarly, if an isolated event is expected, the event command 
can precede ihe name of a file with which the arriving event 
will be compared. Oilier commands, such as a shell escape 
to execute any user command, allow customized testing. 
For example, a shell escape allows Ihe test designer to send 
a signal 10 the agent process lo trigger some behavior, such 
as the sending of an event. This simulates the behavior of 
the agent in actual operation where some asynchronous 
condition might cause the event, while still allowing the lesl 
process to receive a predictable si ream of responses from the 
agent Other commands allow finer control over ihe testing 
process. For example, a timeout value can be set that con- 
trols how long the tester will wail for a response before 
aborting any single test. An example of a lest director file 
with some of these commands included is as follow s: 

tt Comments begin with the '#' character 

It The following files are regular tests to get 

tt the attributes in the already-created 

tt Root Managed Object Class 

root/passFileMOC/getall 

tt Some of the next tests expect both a response 
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# and an event 

pair root/passFil eMOC / pas sEnt ryMOC / creat e 

root/passFileMOC/passEntryMOC/getall 

pair root /pas sFileMOC/passEnt ryMOC /set 

root /pa ssFileMOC /pas sEnt ryMOC/ get 

pair root /pas sFileMOC/passEnt ryMOC /delete 

# Set the timeout to 30 seconds 
timeout 30 

# Send a DNIX signal that triggers an event 
! kill SIGINT $(AGENT_PID) 

tt Receive the event 

event root /pas sFil eMOC /pas SEnt ryMOC /event 1 

Finer Control of the Generation Process 

A powerful feature of the object -oriented design methodology 
is that the standards bodies have invested much energy into 
Constructing managed object class building blocks. A Side- 
effect, however, is that in most cases the standard documents 
from which specific agents inherit contain far more definitions 
than are needed for that agent. In I he case of the Managed 
( Ibjeet Toolkit, this causes needless code to be generated, 
producing a larger agent than is required. To counteract this 
effect, the Managed Object Toolkit allows developers to 
specify a subset of the managed object classes, so that code 
Is generated only for that subset. The Agent Tester Toolkit 
accepts the same subset specifier, and tests are generated 
only for that subset. 

In some cases, greater control over the nature of the gener- 
ated tests is needed than simply selecting a subset of man- 
aged object classes. An example is the containment tree 
example given in Fig. 1 that began witli a network object as 
the root node. 'Hie GDMO description of a network class 
might allow (as it does in ITI'-T Recommendation M.3100) 
that network to be decomposed into subnetworks and sub- 
subnetworks, and so on. To allow the test designers to specify 
how many levels of decomposition the agent is expecting, a 
containment tree specification file can be provided to the 
lest generator. This specification file is formatted like an 
outline, with the level of indentation indicating how deeply 
under the root node each class is contained. For example, 
the containment tree in Fig. 1 would be depicted: 

network 

> element 

> > regenerator 

> > multiplexer 

(Only one of the element nodes is shown. It will be ex- 
plained later how to include both circuit branches.) 

If the agent is expecting the network level to be expanded 
into network and subnetwork levels, this change can be in- 
corporated in the specification file by introducing another 
network node and indenting its children by an additional 
level: 

network 

> network 

> > element 

> > > regenerator 

> > > multiplexer 

This change adds an element to the distinguished name (cor- 
responding to the subnetwork distinguishing attribute value) 
in each test file, so such containment changes have far- 



reaching effects. Making such decisions early in the Specifica- 
tion phase saves much work compared to adjusting already 
generated test files. 

.As mentioned earlier, the tests are placed in a L'NLX directory 
structure that parallels the containment tree structure, with 
each level named by its associated managed objec t class 
name. In many cases, managed object class names can be 
lengthy, and a pathname to lower-level lest cases composed 
of a sequence of those names can be unwieldy. For example, 
names such as trailTerminationPointBidirectional and connectionTer- 
minationPointSource appear in the standards, and when several 
of these are joined (as is typically done when specifying 
containment relationships), the combination is hard to read. 
To populate the directory structure with shorter, meaningful 
names, a default heuristic is applied that selects a few letters 
from each segment of a managed object class name. For 
example, a file deep in the tr ee described so far might be 
named netw/netw/elem/mult/create. Alternatively, the lest devel- 
oper can override this heuristic by specifying shorter names 
in an optional field in the Specification file: 

network (net) 

> network (subnet) 

> > element (NE) 

> > > regenerator (rs) 

> > > multiplexer (mux) 

Finally, the GDMO document doesn"! specify actual attribute 
values, so the containment tree's distinguishing attributes 
have to be supplied by the test designer. Once again, much 
work is saved by specifying these early, rather than fixing 
tests after they are generated. These distinguishing attrib- 
utes can be assigned in the last optional field of the specifi- 
cation file: 

network (net) networkId="f tc" 

> network (subnet) networkId="Bldgl" 

> > element ( NE2 ) elementld=2 

> > element (NE5) elementld=5 

> > > regenerator (rs) rsld=40 

> > > multiplexer (mux) muxID=56 

Note that by including the distinguishing attribute values, 
we can differentiate between the two element sibling 
branches. 

A supporting tool called ovatct reads GDMO files and pro- 
duces a skeleton specification file similar to the one above 
(using the same subset selection file as the Managed Object 
Toolkit, if provided). More meaningful abbreviations and 
attribute values can be noted in the specification file and 
then used as an input to Hie lest generator to guide the 
production process: 

ovatct gdmo.mib > spec_file 

ovatgen -t /tests -f spec file gdmo.mib 

Summary 

Key design goals of the Agent Tester Toolkit include sup- 
porting agent developers during the development and main- 
tenance phases, and confirming compliance to the GDMO 
specifications the agent is to implement. Also important is 
the ability to generate tests iteralively for evolving designs, 
without time-consuming configuration changes of the test 
engine itself. The Agent Tester Toolkit complements other 
tools in the development life cycle. 
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Storage Management Solutions for 
Distributed Computing Environments 



Strategies for dealing with the vast amounts of data generated by today's 
information technology environments involve more than just larger and 
larger disk drives They include the right combination of different storage 
devices to deal with offline, nearline. and online data storage and 
scalable management software. 

by Reiner Lomb. K < • 1 1 > A. Kino, and Roy M. YanDoorn 



Storage management is fast becoming one or the most im- 
portant issues information technology (IT) managers face 
today. With data accumulating at enormous rates. and with 
end users demanding faster access to more information, 
storage management lias moved from an operation thai was 
done only at night to a mission-critical concern that requires 
lull-time attention. 

Storage management consists of all the activities related to 
the effective deployment, accessibility, and use of stored 
information across a computing infrastructure. Storage man- 
agement involves several major disciplines, including backing 
up and restoring data. Storing data online across multiple 
classes of storage devices such as disks and tape, archiving 
dam for legal and historical purposes, and managing storage 
resources such as I ape or oplical media for optimal use. 
Managing Ihese storage disciplines lakes an effective combi- 
nation of organization, processes, and technologies to meet 
end-user data-availability expectations. 

In today's distributed computing em ironmeuls, IT managers 
need consistent StOiage management strategies and pro- 
cesses across the enterprise in addition, storage manage- 
ment processes cannoi be separated from an integrated net- 
work and system Strategy. Therefore. IT managers need 
complete solutions that integrate the various storage man- 
agement components and technologies such as databases, 

file systems, storage peripherals, storage management appli- 
cations, and network and sysiem management strategies. 

in the past, storage management solutions have been propri- 
etary (mainframes) or piecemeal (early client/server point 
products), with specific peripherals working only with spe- 
cific software and hardware. It was difficult tO expand a 
solution to meel the demands of rapidly growing collections 
of data. 

In ibis article we- will describe trends driving storage man- 
agement technology and the components thai make up an 
ideal storage management solution. Finally, we'll introduce 
III* hardware and software products, services, and partners 
and describe how they work together providing storage 
solutions for our customers. 



Storage Management Trends 

Traditionally, the task of storage management was done 
after work hours when the system could be brought down 
for storage management functions such as backup and 
archiving. Today, much more data is generated, and storage 
management solutions need lo provide much greater data 
availability and reliability. Complicating storage management 
are variables thai determine data throughput ami access. 
These variables include disk capacity, (IT. input/output 
channels, device speed, networks, and software (Fig. 1). 
New ways of transferring and storing large amounts of data 
without downtime have to be developed: 

Probably the most important driving factor in storage man- 
agemeni today is that customers demand continuous acces- 
sibility to huge amounts of data, very often in the terabyte 
range. You can see this demand occurring in the increased 
use of the Internet and online services such as CompuServe 
and America Online, and in I he emergence of new applica- 
tions such as imaging and multimedia in the past, data 
accessibility was a fairly simple process when mainframes 
were the primary storage devices and the only limitation 
was disk size. Today, the answers lo storage problems 
cannoi be provided simply by Installing a bigger disk on a 
central server. 

As customers reenginecr their businesses, many are choos- 
ing to migrate away from the mainframe via "mainframe 
downsizing." Mission-critical applications arc moving to 
open systems; and the management of client/server work- 
groups is being consolidated across LAN's anil WANs. An 
enormous amount of company-sensitive data, which used to 
be under central control and located in the data center, is 
now distributed and available on the network (Fig. Pub- 
lished market numbers show that the average amount of 
distributed data has surpassed the average amount of data 
in the data center. Companies must begin viewing Storage 
management as integral to their network and system man- 
agement solutions. 



© Copr. 1949-1998 Hewlett-Packard Co. 



October lflB6 Howlott-P»ck«rd Jotin»l 81 



CPU and 
Software 



MniMiiiiiiiiiniiit 
IIIIIIIIIUIMIIIMIII 
nmiiHHiiiiiiiiiM 
iiiiiiiiiiriiiiiiiiiii 

IIMIHIIIIIItMIIIIII 



I/O Channel 
Number ol Channels 





IIIIIIHIIIIMIItlMII 

l:!Bis9 



J! jjllKjliil !!»!! 

!i iiiiiiiiiii :!!!:! 



MIIIIMMiniUIIIMI 
lllllliMMIIIIMMHI 
lllllinilllllllllllll 
IIIIllllIIUIIIMHiM 
IIIIIIMIIHMIIHIIK 



MMfMIIMMP 
Mill lllllllllilMI 

' 

mil itiiiiMiiiiu 

III" MlllltlKillt 



Fig. l. Components In the chain 
thai have ail impact on data 
throughput. 



In addition to all the challenges raised by managing storage 
on distributed systems, IT managers must deal with the 
reality that the amount of data being stored is outstripping 
the network's capacity to handle it efficiently (Fig. 3). For 
example, a company might need to back up 100 Gbytes of 
dala in an hour. As the storage staff looks for solutions, they 
see processor performance improving faster than disk per- 
formance. They also see the performance of both disks and 
processors outstripping the performance of the installed 
network infrastructure. At the rate network infrastructure is 
improving, il will be a huge challenge to catch up to proces- 
sor performance. 

If IT managers try to win this conlesl wilh only the tradi- 
tional approach ol" centrally stored data, they will lose the 
storage managemenl race. Instead, today's storage manage- 
ment solutions must allow distributed storage management 
to be performed centrally, decentrally, or in a hybrid fashion, 
depending on a company's policies and needs. 

To solve the growing issue of storage management, they 
need to understand what constitutes a storage management 
solution. 

Storage Management Requirements 

The ideal storage management solution, which is made up of 
complementary software, systems, and peripherals, is inte- 
grated, scalable, and modular, and allow s the solution to be 
implemented in phases and expanded over time. A flexible 
solution addresses both mission-critical enterprise-wide 
requirements and business-critical desktop needs. At the 
same time, this solut ion must be easy to use and robust, and 
must provide quick, reliable access to data. 

The fundamental requirement of any storage management 
system is to provide data accessibility to all users, regard- 
less of where and how the data is stored. To make data 
quickly accessible, yet store it efficiently, customers need a 
complete, integrated set of storage management functions. 



including backup and recovery, archiving and retrieving, 
hierarchical storage management, and media management. 

hi addition, an enterprise- wide storage solution must allow 
various storage management applications and peripherals to 
manipulate and share media in a consistent manner. It must 
also provide an easy and standardized way to access die 
various storage devices, library systems, and silos. Many 
companies are dedicating servers to specific tasks such as 
backup and restore servers or archival and retrieval servers. 
A storage solution must be optimized so data is stored and 
moved in the most efficient maimer. 

Other more generic services for storage managemenl include 
a central policy definition and a single point of conl rol." 
Lights-out operation and tuiattended remote backup are also 
key to many storage management solutions. " Storage man- 
agement solutions are most manageable when integrated 
into management systems such as HP OpenView, which pro- 
vides integrated network and system management services 
dealing with monitoring, problem management, and configu- 
ration and change services. 

Backup and Recovery 

One of the most important needs in enterprise-wide storage 
is backup and recovery. Very early in a solution deployment, 
IT managers must establish a backup and recovery policy 
that provides the appropriate level of data integrity. This 
policy must ensure that critical data can be completely and 
quickly recovered from a backup even in the event of a 
disaster. Equally critical is minimizing planned downtime, 
or completely avoiding downtime, to create a backup while 
keeping user applications up and running. 

A central policy describes a set of features that allow an administrator to define policies about 
how distributed storage is to be managed from a central management console. For enample. 
an administrator defines for a networked environment which data needs to be backed up, 
when it will be backed up. which device will be used tor backup, and so on. 

In the IT community lights-out operation means that an It environment can run without local 
operators or administrators 
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Fig. 2. Decentralized storage management committed to same service level as a mainframe environment, 



Archiving and Retrieving 

The main reason for implementing archival and retrieval 
solutions is the need to keep data long-term and guarantee 
retrieval when access is required. The data is typically 
copied onto a different medium such as tape or optical disk, 
while the original copy is deleted from magnetic disk. 
Archived data is not frequently accessed. 1ml sophisticated 
retrieval mechanisms need to he available. In many cases, 
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Fig. 3. The volume of data being stored is outstripping the ability of 
network services to deal with it. 



archiving data is required for legal or Interna] auditing pur- 
poses. The archiving procedure includes storing data that 
logically belongs together in long-term storage, such as a 
finished project, a finished design, or a client record. 

Hierarchical Storage Management 

Hierarchical storage management, or I ISM. efficiently man- 
ages data stored on magnetic disks, optical disks, and tapes. 
Depending on cost versus performance requirements, data 
is kept on one or more of the different storage hierarchy 
levels and migrated transparently among the storage media 
according to customer-defined policies. An I ISM system 
reduces ongoing storage configuration tasks, such as moving 
data manually between levels in the hierarchy and subse- 
quent management costs. It also eliminates frequent storage 
maintenance, such as manually archiv ing files onto tape to 
free disk space, and it helps reduce the need to acquire 
more expensive media, such as magnetic disks, for infre- 
quently accessed data For example, files are migrated from 
disk to tape or optical storage if they are not accessed for a 
certain time period. Statistical data about access patterns 
can help to define the right migration policy. Also, keeping 
statistical data about migration patterns and creating appro- 
priate reports will help to implement the right storage man- 
agement policies for an organization. 
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Media Management 

The storage services discussed above handle copying ( >r 

moving dala onto media or retrieving data from media. 
Media management, which keeps Irack of removable media 
such as tapes or optical devices, deals with the medium it- 
sell" and not with the dala on I he medium. A media manage- 
ment system protects data on the media and makes the 
media pools available to storage management applications. 
Typical media management functions include mount and 
unmount media, rotate media, and provide statistical infor- 
mation about the media. 

Most of today's backup, retrieval, archival, or EiSM products 
have their own integrated media management functionality 
dedicated to a specific product. Enterprise storage manage- 
ment solutions require generic media management services 
delivered in an integrated way, so that media use can be 
managed and optimized across applications and systems. 

Enterprise-Wide Storage Management 

IT departments also require consistent and effective man- 
agement capabilities for storage management across the 
enterprise environment To provide these management 
services, a complete storage solution must provide: 
A single point of control, which is consolidated console 
management , including: 

Central policy definition 

Central monitoring and problem management 

Central configuration of storage 
Mullivendor availability and support 
Scalable, modular services 

Integration with an industry-standard network and system 
management framework 

High availability of key storage management components. 

HP Storage Management Solutions 

HP can offer many different solutions to an organization's 
storage needs because of the combined effort of major HP 
business Organizations in the areas of netw ork and system 
management, storage peripherals, and UNIX® servers. 



However, each customer's needs for storage management 
solutions are different. No one vendor can provide a single 
solution for every environment. Rather than create a mono- 
lithic, proprietary solution. HP is working closely with third- 
party partners and many div erse HP divisions to create an 
open, standardized environment in which many vendors can 
participate in creating solutions. 

HP Storage Management Software 

Central to HP's storage management offering is the software 
thai links all the other pieces of a storage management solu- 
tion together. HP's two leading storage management prod- 
ucts. IIP Open View OmniBack II and HP Open View Omni- 
Storage, are client/server solutions that give IT managers 
the flexibility to manage distributed storage centrally and 
delegate management responsibility to distributed sites or 
departments, HP < hnniBack II products address issues asso- 
ciated with dala loss and protect!! >n. and IIP* UBigB M ttgB 
products address issues associated with space management. 

HP OpenView OmniBack II. IIP offers two backup solutions: 
HP OpenView OmniBack II for Workgroups, which provides 
an entry-level backup solution ideally suited for the work- 
group environment, and HP OpenView OmniBack II. which 

provides a comprehensive backup management solution to 
coverall sizes of environments, including the whole enter- 
prise. 

The HP OmniBack II architecture (Fig. -I) consists of three 
major pieces: 

• Backup Manager. This module centrally administers and 
controls the backup environment. 

• Backup Device Servers, These servers run on the system to 
which the backup device is connected. A backup environ- 
ment can have many backup device servers. 

• Clients. All systems being hacked up need a client to invoke 
the backup utilities. 

All three components can run on the same system or can be 
distributed. OmniBack II has il-s own management interface 
and can be run inside or outside the IIP Openview manage- 
ment interface. 




Backup Environment 



Fig. 4. The backup environment 
ami components for IIP OpenView 
OmniBack II. 
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OniniBark II is a scalable and flexible solution. Through 
its policy-driven, centrally managed, automated backup 
capabilities, OmniBack II reliably protects data distributed 
throughout the entire network. Easy-to-use backup and re- 
store functionality provides management for desktop PCs to 
I "NLX-based business servers. In combination with HI' < (pen- 
View fT/Operations. administration and problem management 
for the entire enterprise can In- centralized 

Sophisticated media and devic e management combined with 
support for mainframe-class library systems, including silos, 
make OmniBack II the ideal solution for data centers." 

Increased Uptime for application and database servers can 
l>e achieved through high-performance offline backup, re- 
quiring only a minimum of application downtime. This can 
be extended to 100% application availability through online 
backup Of business data. 

The main features provided by OmniBack II include: 

Network backup and recovery 

Support for a broad range of devices and libraries 

< Inline backup of applications and databases such as 

SAIVR3. Oracle, and Sybase 

Sophisticated media management 

Support for major UNIX and PC platforms, including 

Windows NT 

High-performance backup and recovery from multiple 
drives in parallel, each running at its full native throughput 
Integration with IIP Open View IT/t )peralions 
Integration with HP Open View OmniStorage, HP's hierarchi- 
cal storage management solution. 

HP OpenView OmniBack II for Workgroups. < ImniBack II for 
Workgroups is a complete solution that offers everything 
needed for a low-administration, automatic, unattended, and 
reliable network backup and recovery solution. It is targeted 
toward smaller rnullivendor computing environments with- 
out dedicated administrators. OmniBack II for Workgroups 
includes the following features: 

Automated and reliable network file system backup and 

recovery 

Sophisticated and automated media management, auto- 
loader support 

Support for all major UNIX and PC platforms 
Easy-to-use intuitive graphical user interface with many 
built-in browsers and select ion lists. 

HP OpenView OmniStorage. I imniSloragc is Ill's hierarchical 
storage- management solution. It offers benefits in environ- 
ments where a significant amount of data needs to be on- 
line, but where not all of the data is fretiiieutly accessed. 

i tmniSiorage provides high-capacity, cost-effective online 
storage by supporting HP's broad range of optical libraries 
and the newest tape libraries. According to policies defined 
by the customer, tiles arc- automatically and transparently 
migrated among the levels of storage hierarchy. 

Fig. 5 shows a typical environment in whic h t imiiiStoragc 
runs. Tin- two main pieces oft ImniSlorage- are the manager 
and the clients. The manager administers and controls the 

storage environment, and the- clients invoke the Omni- 
Storage functions On behalf of users. 

Silm are very lugs tape libraries 



OmniStorage is tightly integrated with IIP Open View IT 
Operations, providing easy aeiministration and problem 
management of multiple OmniStorage installations from a 
central workstation console. OmniStorage also integrates 
with OmniBack II for automated backup and recovery of the 
HSM enviroiuuent. However. OmniStorage can run as a 
standalone product, which allows customers to implement 
storage management in phases. 

OmniStorage provides optimal performance if users fre- 
quently accc-ss only a subset of the data Additionally, t iiiini- 
Storage can be used for databases if they are based on a file 
system and if major parts of the database, such as decision 
support systems, are not frequently accessed. 

Finally, t imniStorage provides the following features: 

• Policy-driven automatic- and transparent file migration 

• Network migration for HP I X' and Solaris operating 
systems 

• Additional rnullivendor support through NFS 

• Exceptionally fast rebuild c apabilities in case of data loss 

• Configurable demigration strategy 

• Archival to W< >HM (write- once, read many) disks 

• Integration with HP ( ipenVicw < ImniBack II 

• Integration with HP IT/Operations 

• Support for data warehouse environments. 

HP OpenView Solutions 

HP OpenView s solutions are part of a strategy for managing 
muliivendor networks, systems, applications, and databases 
from the mainframe to the desktop PC. The IIP • IpenVicw 
portfolio and companies that provide network and system 
management solutions (solution partners) give IT managers 
the tools to control and manage all enterprise resources and 
devices centrally, while reducing the cost of systems opera- 
tions and administration. Besides ( ImniBac k and ( Imni- 
Slorage. more than 250 HP < Ipen View-based management 
solutions from IIP and solution partners integrate with a 

complete set of common management services to help 
customers improve service and reduce operation costs. 
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Fig. a. The components and envtaMiittenl Co* III' I IpenVlew < hunt 
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Central lo the HP Open View products is a user interface Dial 
provides a foeai point from which I he IT staff can manage 
computer systems and network devices. Although control is 
centralized through the interlace, management functions can 
be distributed across the enterprise. More important, flexible, 
distributed interfaces allow several operators and adminis- 
trators to be involved in the process of IT management. 

As an important pan of the IIP OpenView solutions frame- 
work. IIP Open View IT/Operation.s provides centralized 
operations and problem management with distributed intel- 
ligence across muliivendor platforms. With intelligent agents 
(managed nodes) installed throughout the enterprise, IT/ 
Operations collects up-to-date, accurate information to pro- 
vide 24 * 7 (24 hours a (lay. seven days a week I uptime for 
mission-critical applications. IT/Operat ions-managed nodes 
gather information, messages, and monitoring values from a 
variety of sources, Filters and thresholds ensure that only 
relevant information is forwarded to the central manage- 
ment system and presented to the responsible IT/Operalions 
operators. 

HP and Third-Party Storage Peripherals 

The IIP IIOOO supports mass storage products that provide 
online, nearline. and offline storage capabilities. The pri- 
mary differentiator among these three categories of storage 
is access time. A storage device is considered online when 
the data access time is a fraction of a second. Nearline stor- 
age devices usually access data in the nmge of a few seconds 
to a few minutes. Offline storage devices typically require 
many minutes to hours to access data. .Some offline storage 
strategies that require retrieval from a storage vault may 
take days before the data is available lo the user. 

HP and its partners can provide a wide variety of products 
lo meet the individual needs of specific customer environ- 
ments. These products can be mixed and combined wilh 
HP's storage management software (0 provide the needed 

end-user solutions . 

Online Storage 

IIP offers two classes of online mass storage products: 
single-spindle disks and disk arrays, 

Single-Spindle Disks. Single-spindle disks Offered by III 1 arc 
either embedded in the host systems or provided externally 
Within storage enclosures. These disks provide high-capacity, 
nonvolatile, fast-ac cess mass storage. Single-spindle drives 
operate at 72110 rpm and are currently available in capacities 
of l.OotJhyres. 2.1 Chyles, and 4.3 Gbytcsas fast/wide dif- 
ferential drives. 

These new drives are available as embedded devices in ail Of 
the IIP 9000 servers, more than doubling the Interna] online 
storage capacity. With the addition ofthe 4.3-Gbyte drive, 
21,5 Gbyt.es of external online storage capacity can now be 
housed in a single enclosure rack with up to Kill Gbyles in a 
l.li-meter-high cabinet. 

' A r.nllection of disk planets on a single spindle 



HP External Storage Enclosures HP offers two families of stor- 
age enclosures for online storage: the IIP (iOOO SCSI mass 
storage family and the IIP high-availability storage system. 
HP*s high-availability storage system is based on a package 
design thai delivers flexibility and ease of use while providing 
critical functionality lo meet the needs ofthe enterprise. The 
system provides excellent availability, hot-pluggable power 
supplies, dual, power cords, cooling fans, and hot-pluggable 
storage modules. The subsystem connects lo the server via 
dual SCSI buses, increasing reliability and enabling disk 
mirroring in the same enclosure. 

HP Disk Arrays. A disk array is a storage system consisting i .1 
multiple disk driv e mechanisms under the conmiiuid of an 
array controller that communicates with the host (Fig. ti). 1 
The key benefit of disk arrays is high data protection Arrays 
also provide high storage capacities, connectivity, and con- 
figuration flexibility. 

HP currently offers three primary disk array families associ- 
ated with the HP 0000 business server product line. The first 
family is the IIP high-availability disk arrays Model 1(1 and 
Model 20, which have a raw capacity of (i to SO (i bytes, sup- 
port RAID levels 1 and 5. and have dual and hol-swappable 
Controllers and redundant cooling and power.' 

The second disk array offering is EMCs Symmctrix :10()0. 
The Symmetric 300(1 is a high-performance inlegraled-cache 
disk array designed for online storage. As such, the Symme- 
trix 3000 prov ides a high level of online performance, an 
online capacity of up to 1.1 terabyte, and manageability and 
high availability lo IIP 9Q0O business servers. The result is a 
mainframe-class data storage solution thai is simple lo man- 
age and is delivered in a high-performing, scalable, protected, 
and open architecture. 

The final disk array is the faull-lolerant. self-configuring, 
high-performanc e IIP disk array produc t with AuloRAID 
technology. The HP AuloRAID disk array eliminates the 
need for system administrators to understand RAID levels. 
It dynamic ally adapts to the systems workload, thus opti- 
mizing for performance and cost. Finally, il offers a raw 
capac ity of up to 24 gigabytes. 

RAID = Redundant Array or" Independenl Disks 
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Fij{. 6. A lypical RAID architecture. 
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Nearline Storage 

Most files and applications stored on hard disks are never 
used. Thus, the major benefit of hard disks — high-perfor- 
mance access — is squandered on dormant data. Cost-sensi- 
tive environments would be better served by a hierarchical 
storage management solution in which active data is stored 
on hard disks, while dormant or infrequently used data is 
cost-effectively stored offline or nearline in media such as 
optical disks. 

HP SureStore Optical Storage Products. HP Offers a broad family 
of optical disk drives, ranging in capacity from 40 Gbytes to 
618 Gbytes. HP offers multifunction magnetooptical drives 
with rewritable and WORM disks. A rewritable optical disk 
BO) be written up to 10 million times. A WORM disk can be 
written once but cannot be erased or overwritten, adding a 
higher degree of security. 

The main features of these nearline storage devices include: 
Fast, near-hard-disk transfer and seek times 
High capacity 

Low risk — no disk crashes with optical disks 
Online data availability on a random-access device 
Online drive replacement— provides assurance that the 
optical system is persistently available 
Remov able media 

Long life — provides more than 100 years of media life 
without maintenance. 

Offline Storage 

HP's range of offline storage products provide high speeds 
and large capacities to meet the increasing demands of HP's 
high-performance workstations, network servers, and multi- 
user systems. HP has combined its reliable DAT products 
with an industry-leading autoloader design and networking 
soft ware to give customers the flexibility they need for com- 
plete automated network backup." 

HP DAT Products. HP offers the latest DDS-2 tape drives in 
addition to DDS and DOS DC drives. The new DDS-2 format, 
combined with 120-meter tapes, has a native mode c apacity 
of -1 Gbytes. With data compression, customers can typically 
store S Gbytes on a single tape. For unattended or lights-out 
operation, a six-cartridge autochanger is available to rotate 
media for full and incremental backup and restore opera- 
tions. HP also supports 8 mm and QIC tape drives. The main 
features of these offline storage products include: 
Unattended backup 
High capacity with high reliability 
Easy storage in a fireproof safe according to industry 
standards 

DDS format can be interchanged w ith different 
manufacturers' tape drives. 

Digital Linear Tape. HP 9000 servers support the HP] ILT 
(digital linear tape) Library 4/48. This library consists of four 
Quantum DLT/4000 drives, accommodating 4S :>0-( Jbyte tape 
cartridges and providing greater cartridge capacity than the 
DDS format. The DLT/4000 is a 0.5-in cartridge streaming 
tape with a capacity of 10 (ibyl.es per cartridge (with 2:1 
compression ), and a sustained transfer rate of 3 Mbytes/s. 
The IIP DLT Library 4/48 enables fast, unattended backup or 
over 100 Gbytes of data within the brief windows of time 
available for backup in high end < )LTP (online transaction 



processing) and decision support system environments 
(Fig 7). 

The main features of digital linear tape include: 

• A native-mode data transfer rate three times faster than 
competing technologies 

• Greater media and drive head longevity 

• Sophisticated tape indexing for fast-streaming file searches 
and restoration 

• Higher compression ratio for most data types. 

• Driver support provided by IIP for the 18-track StorageTek 
tape drives (model 4781 ) and the 36-traek single-ended tape 
drives (model 4791 ). 

3480/3490 Compatible Tape Subsystems. Libraries, and Silos. 

HP provides driver support for 18-track StorageTek tape 
drives (Model 4781 ) and 3(vtrack single-ended tape drives 
(Model 4791). Additionally. StorageTek offers Timberline 
9490. a fast wide implementation of the Model 4791 with 
a 6-Mbyte/s drive. These drives are compatible with all 
StorageTek silos. HP supports StorageTek silos, including 
one with a 500-cartridge capacity and 90 cartridges/hour 
(upgradable to 1000 cartridges and 360 cartridges/hour) and 
another with a 0000-cart ridge capacity and 350 cartridges/ 
hour. Doth connect to other devices and silos for easy 
growth. 

ITP 9000 Business Servers 

Today's open systems for critical business computing envi- 
ronments require three essential elements. First, they must 
provide the storage management, data integrity, security, 
and manageability that information technology managers 
have come to expect in running business-critical applications 
on centralized processing systems. Second, they must pro- 
vide connectivity and compatibility with the growing base of 
PC desktop users. Finally, they must offer flexibility, perfor- 
mance scalability, and technical innovation to keep up with 
emerging application demands. 

As the leading open systems platform, HP 9000 business 
servers offer the benefits of all three elements in a single, 
Unified, I NIX-based platform. The IIP 9000 server platform 
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is able (o support environments oral] sizes, ranging from 
workgroups anil replicated sites in (he departments and 
data centers oflarge enterprises. For slorage management, 
the IIP 9000 business servers offer the following features: 

• Highly available and reliable systems environnienl 

• Excellent daia-movement management 

• A dedicated storage server architecture that is designed for 
optimal database and file management 

• Scalable from desklop to data center 

• Hundreds of partners that ensure customizable solutions. 

Storage Solutions for the Enterprise 

To help understand how tp plan a complete storage manage- 
ment solution, we have looked at scenarios common lo many 
companies Struggling with storage management demands. 
In each of the following examples, we'll examine Ihe needs 
specific to each environment and the needs of centralized 
storage management, stalling with small workgroups, and 
building up lo Ihe enlerprise level. Then we'll show how IIP 
and its parlners can provide a unified solution. 

Independent Workgroups 

Many workgroups implemeni their own backup and recovery 
solutions. These solutions are typically managed by a part- 
time administrator. Major requirements for backup and re- 
covery solutions include ease of use and automation. Omni- 
Back II for Workgroups is Ihe best backup and recovery 
product for independent workgroups. Combined with HP's 
low-COSt, high-performance business servers and HP's DOS 
II device libraries, backup procedures can be automated and 
centrally controlled within the workgroup. OmuiBack II for 
Workgroups provides easy and fast restoration of files and 
the potential to expand the workgroup or even consolidate 
multiple workgroups. 

Solution Elements. The storage management solution from 

HP for independent workgroups includes: 

HP OnmiBack II for Workgroups, with easy-to-use backup 

and recovery software for small environments 

IIP 9000 Class D and E business servers for backup 

HP's DDS II autoloader as a cost-effective tape library. 

Distributed Client/Server Workgroups 

As information technology departments consolidate work- 
group management, they need more centralized storage 
management for dislribiiled, heterogeneous workgroups. 
Two main objectives of this scenario are to increase end 
user productivity by providing homogeneous and powerful 
slorage services, and to increase operator productivity 
through central control and administration of those storage 
services over the LAN. Significant savings can be achieved 
through intelligent resource sharing and reduction of opera- 
tional overhead. 

I )mniBack II centrally manages the complete backup and 
recovery process oflarge numbers of distributed workgroups 
by dividing large numbers of backup nodes into multiple 
manageable backup domains. Central control can be main- 
tained at ihe enterprise console while delegating backup 
and recovery tasks to the individual end-user departments. 
OnmiBack II can automate Ihe complete backup process of 
distributed client/server workgroups. 



In addition, clala on shared file servers and on client disks 
grows dramatically. Migrating infrequently accessed data 
onto different storage media such as optical disks or tapes 
becomes an administrative nightmare. OmniSlorage helps lo 
increase Ihe online storage capacity of clients and servers 
while keeping slorage administration costs under control. 

Solution Elements. The storage management solution from 
IIP for distributed clienl/server workgroups includes: 

• Centrally controlled backup and recover.' for heterogeneous 
workgroups with OmuiBack II 

• Automated backup based on HP's DDS II Autoloader or HIT 
libraries 

• HP 9000 business servers used as reliable and high-perform- 
ing backup, restore, and I ISM servers. 

• Unlimited online slorage based on OmniStorage combined 
with HP's optical or tape libraries 

• Sophisticated problem management with HP IT/Operations. 

Regional Distributed Systems and WAN Connections 

Companies with branch offices in Ihe retail or financial indus- 
tries, for example, often have regional distributed .systems 
connected via WANs. IT depart ments for these companies 
need to run the IT infrastructure of the branch offices with- 
out operators or administrators. Remote control and admin- 
istration of storage services over the WAN are essential. 

OnmiBack II defines each remote branch office as a backup 
domain with one or more local backup servers. The complete 
backup and recovery administration process and control 
can be performed from a central console via WAN. By 
choosing the appropriate devices, with Sufficient capacity 
for each of the remote offices, Ihe backup and recovery pro- 
cess for the branch offices can be performed remotely. 

Solution Elements. For regionally distributed systems the 
slorage management solution from IIP would include: 

• Central backup and recovery for remote sites with Onmi- 
Back 0 

• IIP 9000 Class D and E business servers for reliable backup 
and recovery at branches 

• HP's DDS II autoloader for automated tape handling 

• HP IT/Opcrations integration of OnmiBack II for sophisti- 
cated central problem management. 

Data Center and Mainframe Downsizing 

When customers migrate from Ihe mainframe lo open sys- 
tems, they expect the same functionality and scalability in 
storage services as they had with the mainframe. The IT 
department is expected to continue lo provide Ihe same 
level of assurance that computer services are available, 
reliable, and secure. 

For example, a major multinational company using the 
HP-UX operating system with large SAP/R3 projects based 
on Oracle requires efficient, reliable, unattended automated 
backups and restores. These backups are in the multiple 
lerabyie-per-vveek range and w ill move into 2-1x7 (24 hours 
a day. 7 days a week) operation. OmuiBack II is a key part of 
the solution because it gives the customer online backup by 
integrating with either the SAP/R3 online utility or the 
Oracle database utility. OnmiBack II also integrates with 
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IT/Operations. This customer has complete centralized man- 1 Gbyte of magnetic disk capacity assigned lo 5 or 10 Gbytes 
agement of all backup sessions and devices with the option of optical capacity) have been implemented successfully, 
of managing a partially or fully distributed environment E|ements ^ provides ^ following s|orage I11;uv 

Because of OmniBack U s modularity and integration with agement solutions for data warehouses: 

other online backup services, such as those provided by • Automated data migration with OmniStorage 

Oracle and Sybase, customers can configure OmniBack II • Online access to secondary and tertiary storage through 

to expand to match their growing infrastructures. Many HP's optical and tape libraries 

customers also may choose to add HP's MlTServiceGuard • High-performance data warehouse applications based on 
to ensure high availability of stored data HP 9000 1 'lass K anil T business servers. 



Solutions Elements 

Data centers needing high-end backup and restore are pre- 
sented with the following storage management solutions 
from HP: 

High degree of automation with OmniBack II and Storage- 
Tek's Tape Silo 

High backup and restore performance using StorageTek's 
Tiinberline tape drives 

High reliability through HP 9000 systems running the HP-l'X 
operating system 

SAP/R3 online backup with OmniBack II integration 

Enterprise monitoring and problem management through 

HP IT/Operations integrated with OmniBack II 

Full consulting, from investigation through implementation. 

by HP's professional consulting services 

HP MC/ServiceGtianl. 

Data Warehousing: Scalable Storage Infrastructure 

Much of a company's data remains valuable but does not 
need lo be online and available all the time. Typical storage 
capacity requirements of data warehouses range from tens 
of gigabytes to several terabytes. Storage managers need the 
ability to move this data cleanly from primary to secondary 
storage and back to primary temporarily, as needed. 

The combination of HP's business servers, magnetic disks, 
optical disks, and < (mniStorage offer an ideal storage infra- 
structure for data warehouse environments. This solution 
offers efficient storage hardware costs and high scalability 
for large storage capacities. 

The ideal ratio between magnetic and optical capacity de- 
pends on environment Patios in the range of 1:5 to 1:1(1 1 i.e.. 



Conclusion 

The ideal storage system would provide complete and inte- 
grated storage management functionality, smooth integration 
with multiple file systems and databases across a broad sw 
of operating systems, and support for a large variety of peri- 
pherals to satisfy the needs of different storage management 
applications. Preventing this ideal solution from occurring 
are a multitude of nonintegrated storage components from 
different vendors. This situation forces administrators to use 
single-unit solutions for storage management, which leads to 
redundant and inconsistent management environments. 

The HP storage architecture offers a streamlined and unified 
interaction among diverse storage components. This archi- 
tecture allows for customized solutions using plug-and-play 
components and enables different storage components to 
interact consistently. For example. HP's backup solutions 
are being integrated via APIs with databases such as Oracle 
and Sybase. 
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the National Endowment for The Arts, for the lobby 
of the Federal building in Columbia, South Carolina 
Currently she is working on silk painting and other 
fabric dyeing techniques, and is remodeling her 
recently purchased 70-year-old house 
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Born m Sacramento. Califor- 
nia Judy Smith received a 
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in computer science from 
California State University at 
Sacramento in 1985 After 
graduating she ]0ined HP's 
Roseville Networks Division 
She is currently a learning 
products engineer at HP's Networked Computing Divi- 
sion and is responsible for developing learning prod- 
ucts for future Fibre Channel VLSI chips and adapter 
boards Recently she was the simulation engineer re- 
sponsible for designing and implementing the testing 
for the Tachyon chip and another VLSI chip Previously 
she was the simulation engineer for a fast-wide SCSI 
chip Before that she designed, implemented, and 
tested diagnostics for FDDI and LAN adapters and 
firmware for HP's OSI Express card She has co- 
authared a previous HP Journal article on the OSI 
Express data link layer and contributed to the Fibre 
Channel/9000 product manual. She is a member of 
the Society of Technical Communicators and a found- 
ing member of the Sierra Foothills Chapter of the 
Society of Women Engineers. Judy is married and 
has one son. Her husband also works at HP In her 
free time, she is a volunteer on the HP Roseville 
donations committee and is an advisor to California 
State University, Sacramento, on its technical writing 
curriculum She sings baritone with Sacramento 
Valley Chorus, a chapter of Sweet Adelines Interna- 
tional, she enioys being a mom, and she likes to read 
about a variety of topics, especially child development 
and world religions. 



Meryem Primmer 

Autfior's biographv appears elsewhets in this section 



© Copr. 1949-1998 Hewlett-Packard Co. 



Odolier lllUli Hewloii-Pai'kard Journal 93 



An Introduction to Fibre Channel 



Fibre Channel is a flexible, scalable, high-speed data transfer interface 
that can operate over a variety of both copper wire and optical fiber at 
data rates up to 250 times faster than existing communications interfaces. 
Networking and I/O protocols, such as SCSI commands, are mapped to 
Fibre Channel constructs, encapsulated, and transported within Fibre 
Channel frames. 

by Meryem Primmer 



Fibre Channel is a standard, efficient, generic transport 
mechanism whose primary task is to transport data at the 
fastesl speeds currently achievable with the least possible 
delay. It is a flexible, scalable method for achieving high- 
speed interconnection, communication, and data transfer 
among heterogeneous systems and peripherals, including 
workstations, mainframes, supercomputers, desktop com- 
puters, and storage devices. It handles bot h networking and 
peripheral I/O communication over a single channel using 
the same drivers, ports, and adapters for both types of com- 
munication. 

Fibre Channel began in the late 1980s as part of the IP] 
(Intelligent Peripheral Interface) Enhanced Physical Project 
to increase the capabilities of the IPI protocol. Thai effort 
widened to investigate other interface protocols as candi- 
dates for augmentation. The first year of the project was 
spent looking for existing implementations to adopt . but 
none were foimd to be sufficient. The focus then changed to 
develop a new implementation. That implementation be- 
came Fibre Channel. Fibre Channel was approved as a proj- 
ect in 1988 by ANSI X3T9. 

During the first year of investigation the ANSI working gr oup 
decided to adopt a serial rather than a parallel bus interface. 
IBM's 8B/IOB encode/decode scheme was adopted, and a 
decision was made lo support both copper cable and optical 
fiber. Copper can be used for low cost w hile optical fiber 
can be used for distance. Fibre is a generic term used by the 
Fibre Channel standard to refer to all the supported physical 
media types. 

The Qrsl draft of the Fibre Channel standard was developed 
in 1989. The standard addresses the need for very fast trans- 
fers of large volumes of data, while at the same time relieving 
systems of the need to support the multitude of chaiuiels 
and networks currently in use. The Filter Channel Standard 
covers networking, storage, and data transfers. In October 
1994 the Fibre Channel physical and signaling interface stan- 
dard. FC-PH, was approved as ANSI standard X3.230-1994. 

Fibre Channel is structured as a set of hierarchical functions 
that support a number of existing protocols, such as SCSI 
(Small Computer System Interface) and IP (Internet Proto- 
col), but it does not have a native I/O command set. It is not 
a high-level protocol like SCSI, but does contain a low-level 
protocol for managing link operations. Fibre Channel is not 



aware of, nor is it concerned with I he content of the user 
data being transported. Networking and I/O protocols, such 
as SCSI commands, are mapped to Fibre Channel constructs 
and encapsulated and transported within Fibre Channel 
frames. The main purpose of Fibre Channel is lo have any 
number of existing protocols operate over a variety of physi- 
cal media and existing cable plants. 

Fibre Channel is a high-speed data transfer interface that 
can operate from 2.5 to 250 times faster than exisling com- 
munications interfaces. Its performance is both scalable and 
extendable and il supports multiple cost/performance levels, 
from small Configurations such as disk arrays and low-cost, 
low-performance I/O devices and small systems lo high- 
performance supercomputers and large distributed systems. 

Fibre Channel runs at torn - speeds (actual data throughput ): 
100 megabytes per second (Mbytes/s), which translates lo 
1002.5 megabaud. 50 Mbytes/s or 531.26 megabaud, 25 
Mbytes/s or 265.625 megabaud. and 12.5 Mbytes/s or 132. S12 
megabaud. A single l()0-Mbyte/s Fibre Channel port can 
replace five 20-Mbyte/s SCSI ports, in terms of raw through- 
put. Fibre Channel provides a total network bandwidth of 
about one gigabit per second. 

Fibre Channel operates over a variety of both copper wire 
and optical liber at scalable distances, as shown in Table L 
Distances are easily extendible using repeaters or switches. 

Fibre Channel provides full duplex operation with separate 
transmit and receive fibers. 

Another advantage of Fibre Channel is that it uses small 
connectors. The serial connectors used for Fibre Channel 
are a fraction of the size of SCSI parallel connectors and 
have fewer pins, thereby reducing the likelihood of physical 
damage. Also, depending on the topology-, many more devices 
can be interconnecled on Fibre Channel than on existing 
channels. 

Topologies 

Fibre Channel can be implemented in three topologies lo 
interconnect varying numbers of devices, called nodes in 
Fibre Channel terminology. The topologies are poinl-to- 
point. arbitrated loop, and crosspoint switched, or fabric (a 
Fibre Channel term for a network of one or more switches 
connecting multiple nodes). Nodes contain one or more 
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ports, such as an I/O adapter, thniugh which they communi- 
cate over Fibre Channel. A generic node port is called an 
X_Porl. The connections between ports are called links. 

Table I 

Fibre Channel Media. Data Rates, 
Distances, and Transmitters 
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ECL = Emitter-Coupled Logic. LW = Longwave. SW = Shortwave. 
LED = Light-Emitting Diode. STP = Shielded Twisled-Pair 

Point-to-point (Fig. 1 ) is a direct channel connection be- 
tween I wo N_Ports, typically between a processor and a 
peripheral de\ (ce conl roller. In this topology exactly two 
devices are connected together. No fabric elements exisl 
and no fabric services, such as name mapping, are necessary. 
Point-to-poini is the default topology. 

Fibre Channel arbitrated loop, or FC-AL, is a method for 
interconnecting from two to 126 devices through attachment 
points called L_Port.s in a loop configuration. I. Ports can 
consist of I/( ) devices and systems of various performance 
levels. FC-AL is a low-cost solution because it does not re- 
quire hubs and switches. FC-AL is a good choice for small to 
medium-sized configurations and provides an upward growth 
path bj interconnecting the loop with a fabric through an 
FLJ'ml. Arbitrated loop is the most common Fibre Channel 

topology. 

Fig. 2 show s the Fibre Channel arbitrated loop topology. A 
prtvaU' loii/i (Fig. 2a) consists only of nodes, called XLJ'orls, 
Old docs not connect With a fabric A pvhl.tr loop ( Fig. 2b) 
connects With a fabric via Ml FI._Port. A disk loop uses the 
loop lopologv to interconnect a number of high-performance 




Servei 



RAID Subsystem 



lal 



Nodel 

System 




Nod* 2 
Storage Array 


N.Port 
Tachyon 




N Port 
Tachyon 


N.Port 

Tachyon 


M | t 

Link 



Fig. 1. (a) Twu devices connected point-to-point, (b) Fibre 
Channel point-to-point topology. Tachyon b Hi's gigabit Fibre 

channel controller chip. 

disks. Tor example, a RAID (Redundant Array of inexpensive 
Disks) device. Fig. 3 shows an office configured in a public 
arbitrated loop topology, and Fig. 4 shows a private disk 
loop. 

All devices on the arbitrated loop share the bandwidth of the 
loop and tl»' management of the loop. No dedicated loop 
master exists, and any node is capable of being the loop 
master, Which node performs the loop master functions is 
negotiated when the loop is initialized. 
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Fig. 2. Eflwe I ihamii'l arbitrated loop topology, (a) Private Loop 
(1.) Public loop 
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Fig. 3. All office configured in a public arbitrated loop topology. 

Each node has equal opportunity to communicate with an- 
other node by arbitrating for temporary ownership of the 
loop. An arbitration scheme using a fairness algorithm is used 
to establish a circuit between two NL_Ports on the loop 
before they can communicate. Only one communication, or 
loop circuit, can be active at a time. After relinquishing the 
loop, an NL_Port cannot win arbitration again until all other 
arbitrating ports have had their turn. 

The third Fibre Channel topology is crosspoint switched, or 
fabric. Fig. 6 shows a generic fabric topology, and Fig. (5 
shows the Fibre Channel fabric topology with a single 
switching or fabric element. 

A fabric topology is implemented as one or more switching 
elements. A fabric- appears as a single entity to attached 
nodes, called F_Ports, even though the fabric can consist of 
multiple switches. Typically, a switch has from four to 16 
F_Ports attached to it. In theory, there is no size limit to the 
number of nodes that can interconnect in a fabric, but ad- 
dressing space limits the number to a maximum of 2 2-1 . The 
fabric topology is good for interconnecting large numbers of 
devices and complex configurations. 




Fig. 4. A private disk loop. 

The structure and operations of the fabric are transparent 
to the F_Ports attached to it. The fabric topology is self- 
managed, with the fabric performing station management 
functions and the routing of frames. Each port only needs to 
manage a point-to-point connection between itself and the 
fabric. 

A Layered Approach 

Fibre Channel is structured as a set of five hierarchical func- 
tional levels (see Fig. 7). The user protocol being transported 
over the Fibre Channel — SCSI or IPI (Intelligent Peripheral 
Interface), for example — is known as the upper level proto- 
col (CLP) and is outside the scope of the Fibre Channel 
layers. The Tachyon Fibre Channel protocol chip described 
in the article on page 99 implements the FC-1 and FC-2 lay- 
ers, which are shaded in Fig. 7. Tachyon also implements 
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Fig. 5. A generic fabric topology- 
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Fig. 6. Fibre Channel falirir topology with a single switching 
element. 

SCSI assists and IP checksumming, shown as shaded boxes 
at the FC-1 level. 

FC-4: The Protocol Mappings Layer. This topmost Fibre Utannel 
level defines the mapping of the I ^LP interfaces to the lower 
Fibre Channel levels. Fibre Channel supports multiple exist- 
ing protocols, including SCSI, IP. and IPI. Each ULP sup- 
ported by Fibre Channel requires a separate FC-4 mapping 
and is specified in a separate FC-4 document. For example, 
the Fibre Channel protocol for SCSI, widen is known as 
FCP, defines a Fibre Channel mapping layer that uses the 
services of the lowest three Fibre Channel layers to transmit 
S( SI command, data, and Status information between a 
SCSI initiator and a SCSI target. I "LPs are not tied to a par- 
ticular physical medium or interface. For example, SCSI is 
supported without requiring a SCSI bus. 

FC-3: The Common Services Layer. Nodes can I"' computer 
systems or peripheral devices. The FC-3 level defines a set 
Of Services Hurt are common across multiple ports of a node. 
The FC-3 layer is still being formulated in the ANSI commit- 
tee arid no functions have been formally defined. 

FC-2: The Framing Protocol Layer. This level defines the signal 
ing protocol, Including the frame and byte structure, which 
is the data transport mechanism used by Fibre Channel. 
Included in this level is the framing protocol used to break 
sequences into individual frames for transmission, flow con- 
trol, 32-bit CRC generation, and various classes of service. 

The FC-2 layer also handles hardware disassembly and re- 
assembly of sequences of data. Defined in this layer are a 
few built-in command primitives, called ordered sets, for 
handling such functions as configuration management, error 
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recovery, frame demarcation, and signaling between two 
ends of a link. 

A f mine ( Fig. 8) is the smallest indivisible unit of user data 
that is sent on the Fibre Channel link. Frames can be vari- 
able in length, up to a maximum of 2148 bytes long. FYame 
size depends on implementation, not hardware or software. 
Each frame contains a four-byte Stan of Frame delimiter, a 
24-byte header, up to 21 12 bytes of FC-t payload consisting 
of zero to 04 bytes of optional headers and zero to 2048 
bytes of L LP data, a four-byte CRC". and a four-byte End of 
Frame delimiter. 

A sequence is a set of one or more related frames. For exam- 
ple, a large file transfer would be accomplished in a sequence 
consisting of multiple frames. 

An exchange contains one or more sequences. It is compara- 
ble to a SCSI I/O process, and is the mechanism for coordi- 
nating the exchange of information between two communi- 
cating N_Ports in a single operation. 

In general, the sequence is the Fibre Channel error recovery 
boundary. That is. selectiv e retransmission of frames for 
error recovery is not supported in the Fibre Channel physi- 
cal and signaling interface. FV-PH. If an error is detected in 
a transmitted frame and the error policy requires error 
recovery, the sequence to which the frame belongs may 
be retransmitted. 

Fibre Channel provides t hree classes of service, which are 
managed by the FC-2 layer. Class 1 dedicated connection 
service provides a dedicated or circuit-switched connection 
between two N_Ports. The connection must be established 
before communication can begin and must be lorn down 
when communication is completed. Class 1 guarantees de- 
livery of frames in the order in which they were transmitted. 
Confirmation of delivery also is provided. Class 2 multiplex 
service provides a connectionless, frame-switched link. De- 
livery is guaranteed, but not necessarily in order if multiple 
routes exist through the fabric. Class 2 also provides ac- 
knowledgement of receipt Class 3 datagram service is a 
connectionless service similar to class 2. but without con- 
firmation of receipt Neither delivery nor rec eipt order is 
guaranteed in class 3. 

FC-1: The Encode/Decode Layer. This layer defines the trans- 
mission protocol, including the 8B/1QB encode/decode 
scheme, byte synchronization, and character-level error 
control. 8B/10B is a de-balanced encode/decode scheme that 
provides good transition density for easier clock recovery 
and character-level error detection. In this scheme, 8-bit 
internal bytes are encoded and transmitted on the Fibre 
Channel link as 10-bit transmission characters. The trans- 
mission characters are converted back into 8-bit bytes at the 
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Fig. 7. i'ihre Channel's five layers. 



Fig. 8. A Fibre Channel frame. 
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receiver. I 'sing id bits lor each diameter provides 1(12-1 pos- 
sible encoded values rather Chan only the 2">(> values that are 
possible forK-bil characters. Sol all of the 102-1 possible 
values are used. To maintain a dc balance on the link, only 
those that contain four zeros and six ones, six zeros and 
four ones, or five zeros and live ones are used. Some of the 
extra 10-bit characters are used for low-level link control. 
Due special character called a roiiiiim is used for byte 
synchronization. 

FC-0: The Physical Layer. PC-0, the lowesl of the Bve levels, 
defines the physical characteristics of the media, including 
cables, connectors, drivers (ECL, LEDs, shortwave lasers, 
longwave lasers, etc.), transmitters, transmission rates, re- 
ceivers, and optical and electrical parameters for a variety 
of data rates and physical media. Reference 1 describes HP 
products that implement the PC-0 layer. 

Collectively, the three lowest layers constitute the Fibre 
Channel physical and signaling interface, PG-PHL FC-P1I is 
a channel/network hybrid. Il supports channel interlaces 
for peripherals — for example, SCSI, II'I. and IIIPP1 (Iligh- 
Perfonnancc Parallel Interface) — as well as network proto- 
cols such as TCP/IP. Ft -I'll is similar enough to a network 



lo gain connectivity, distance, and serial interfaces, while 
being enough like an l/< ) channel to retain simplicity, reli- 
ability, and hardware functionality. 
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Tachyon: A Gigabit Fibre Channel 
Protocol Chip 

The Tachyon chip implements the FC-1 and FC-2 layers of the five-layer 
Fibre Channel standard. The chip enables a seamless interface to the 
physical FC-0 layer and low-cost Fibre Channel attachments for hosts, 
systems, and peripherals on both industry-standard and proprietary buses 
through the Tachyon system interface. It allows sustained gigabit data 
throughput at distance options from ten meters on copper to ten 
kilometers over single-mode optical fiber. 

by Judith A. Smith and Meryem Primmer 



Relentlessly increasing demands of computer systems con- 
tinue to stress existing communication architectures bo their 
limits. Even as processor speeds continue to improve dramat- 
ically, they are barely keeping up with increasing numbers of 
concurrently running applications and ( PI -intensive appli- 
cations, such as mullimedia. with higher data throughput 
requirements. Additionally, as the number of interconnects 
between systems and I/O devices continues lo increase, 
I/O channels become bottlenecks to system performance. 
A channel such as SCSI (Small Computer Systems Inter- 
face), which operates al a maximum throughput ol" 20 mega- 
bytes per second in fast and wide mode, simply cannol keep 
pace willi ever-increasing processor speeds and data rate 
requirements. 

Anot her challenge of contemporary computer systems is die 
trend to more widely distributed systems, which require 
greater interface distances. Current parallel bus intercon- 
nects between systems and their I/O devices cannot operate 
Over the distances needed for true distributed systems, such 
as LANs spanning campus areas and high-availability appli- 
cations requiring remote mirrored disks for disaster recov- 
ery. SCSI, for example, is limited to a distance of six meters 
single-ended (single wire per signal) and 25 meters differen- 
tial (two wires per signal ). 

Current peripheral interconnect protocols are limited in the 
number of devices I hey can interconnect. For example, par- 
allel S( SI can connect eight devices and Hi-bit wide SCSI 
can conned lfi devices. In addition, peripheral connectors 
are becoming loo large to fit into the shrinking footprints of 
systems and peripherals. Other SCSI limitations include half- 
duplex Operation only, lack of a switching capability, inabil- 
ity to interconnect individual buses, and the need for cus- 
tomized drivers and adapters for various types of attached 
devices. 

( ompuler room real estate also is becoming scarce and ex- 
pensive, fueled by increasing numbers of racked computers, 
insufficient room to connect desired numbers of peripheral 
devices, and more complex cabling. At the same lime, data 
Storage requirements are skyrocketing as backups of tera- 
bytes of data are becoming commonplace. An additional 



problem is that ever-increasing amounts of data must be 
backed up over loo-slow LANs, making timely, low-cost 
backups ever more difficult to accomplish. 

For all these reasons, today's parallel bus architectures are 
reaching their limits. Fibre Channel provides solutions to 
many of these limitations. Fibre Channel isa forward-think- 
ing solution to future mass storage and networking require- 
ments. The article on page 94 presents a technical descrip- 
tion of Fibre Channel. 

HP and Fibre Channel 

Searching for a higher-performance serial interface, IIP in- 
vestigated a number of technologies. Ill' chose Fibre Chan- 
nel ov er «il her serial technologies because it supports sus- 
tained gigabit data transfer rates (the fastest throughput of 

any existing Interface}, it allows networking and mass stor- 
age on I he same link, and it is an Open industry standard. 

All hough Fibre Channel faces the challenges of lack of mar- 
ket awareness and industry Coordination and a perception 
that it can he expensive, il is a stronger contender than al- 
ternative serial technologies for a number of important rea- 
sons. It is an open industry standard and an approved ANSI 
Standard, it has vendor Support from switch, hub, and disk 
drive suppliers, it is extensible, offering three topologies and 
four data transfer rales, and it supports both networking and 
mass storage. 

Fibre Channel's increased bandwidth provides distance flex- 
ibility, increased addressability, and simplified cabling. Fibre 
Channel has versatility, room for growth, and qualified ven- 
dor support. Mass storage suppliers are using Fibre Channel 
to interconnect subsystems and systems and to control em- 
bedded disk drives. Some midrange system (server) suppli- 
ers are using Fibre Channel as a clustering interconnect and 
Tor specialized networking. Fibre Channel supporters and 
developers include HP. Sun Microsystems. SCI, and IBM for 
workstations, IIP, Sun, Unisys, and Compaq in the server 
market, IIP. Seagate, Quantum, and Western Digital for disk 
drives, and Data (ieneraKs Clariion Business Unit, DEC, 
Synibios, Fujitsu, and EMC for disk arrays, in addition to 
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over 100 other vendors (source: The Fibre Channel Associa- 
tion). 

Fibre C hannel's main virtue is thai it works as a networking 
interface as well as a channel interface. Fibre C hannel is 
one of three complementary net working technologies thai 
HP sees as the next Step upwards in network performance 
(see Fig. 1 ). The other two technologies are ATM (Asynchro- 
nous Transfer Mode), and IEEE 802.12, which is also known 
as lOOVG-AnyLAN or 100BT 1 Each technology has a set of 
strengths and is best suited to a particular networking niche 
Combined, these technologies support all aspects of net- 
working. 

Botli Fibre Channel and ATM are switched systems. They 
can share the same cable plant and encoding scheme and 
can work together in a network (Fig. 2). However. Fibre 
Channel and ATM standards are evolving independently to 
resolve different customer needs and objectives. ATM. 
which is telecommunications-based, is intended for applica- 
tions that are characterized by "bursty" types of communica- 
tions, thus lending itself to WAN applications. lOOVG-Any- 
LAN or 10015T provides low-cost, high-performance client 
attachments. Fibre Channel is data conununications-based 



and particularly well-adapted for networked and embedded 
mass storage, clustering, and specialized networking appli- 
cations requiring sustained data How rates. 

In addition, Fibre Channel resolves the "slots and watts" 
problem that current symmetric- multiprocessing systems 
have. For example, in 1995, three FDD! pods and six fast 
and wide SCSI ports were required to use fully the I/< > capa- 
bilities of a symmetric multiprocessing HP server. Fibre 
Channel could support these I/O services with. just three 
slots. 

HP's vision of Fibre Channel is that it is at the core of the 
virtual data center containing diverse elements including: 
Fibre Channel switches connecting mainframes and super- 
computers 

Network-attached disk arrays and storage archives 
ATM, FDDI, and Ethernet routers 
Imaging workstations 

Fibre Channel arbitrated loop disks and disk arrays 
High-performance mass storage peripherals 
Low-cost clients 
Clustered systems 

Video, technical, and commercial servers. 

Interoperability and the establishment of a critical mass of 
Fibre Channel products are the keys to the success of Fibre 
Channel. IIP is committed to Fibre Channel and is working 
with partners and standards bodies to ensure interoperabil- 
ity. HP is an active participant in the ANSI Fibre Channel 
Working Group, the Fibre Channel Association ( FCA). and 
the Fibre Channel Systems Initiative, which has been inte- 
grated into the FCA. In 1994 HP purchased Canstar, a Fibre 
Channel switch company, which is now HP's Canadian Net- 
works Operation. IIP has developed Fibre Channel disk 
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drives, gigabit link modules and transceivers, 2 system inter- 
laces, and the Tachyon protocol controller chip, which is the 
subject of this article. HP is using Fibre Channel's versatility 
and speed for high-availability mass storage solutions anil 
clustered system topologies. 

Tachyon Chip 

The system interconnect laboratory of the HP Networked 
Computing Division became interested in Fibre Channel in 
1993 as a method of entering the high-speed serial intercon- 
nect market liecause Fibre Cliannel was the first technology 
that could be used for both networking and mass storage. 
HP decided to develop the Tachyon chip in mid- 1993 after 
investigating which Fibre Channel controller chip to use in a 
Fibre Channel host adapter Card under development for the 
HP 9000 Series 800 K-class server. 3 The investigation deter- 
mined that no available chipset would meet the functional 
or performance requirements, so the decision was made to 
develop a controller internally. 

The Tachyon chip ( Fig. 3) implements the FC-1 and FC-2 
layers of the five-layer Fibre Channel standard (see article, 
page 94). Tachyon s host attach enables low-cost gigabit 
host adapters on industry-standard buses including PCI, 
PMC. S-Bus. VME. EISA. Turbo Channel, and MCA. It is easi- 
ly adaptable both to industry-standard and proprietary buses 
through the Tachyon system interface (a generic interface) 
and provides a seamless interface to GLM-compliant mod- 
ules and components. GLM (gigabaud link module) is a pro- 
file defined by the FCSI (Fibre Channel Systems Initiative) 
and adopted by the FCA (Fibre Channel Association). It is a 
Subset of I he Fibre Channel FC-0 layer. 1 

Tachyon provides gigabit data throughput at distance op- 
tions from 10 meters on copper to 10 kilometers over single- 
mode optical fiber. Tachyon host adapters save system slots, 
minimizing cost and cabling infrastructure. 




Fin- 3. HPTacbyori Fibre Channel amtroUerchtp. 



Tachyon achieves high performance and efficiency because 
many of its lower-level functions are implemented in hard- 
ware, eliminating the need for a separate microprocessor 
chip. Functions such as disassembly of outbound user data 
from sequences into frames, reassembly of inbound data, 
flow control, data encoding and decoding, and simple low- 
level error detection at the transmission character level are 
all built into hardware. One set of hardware supports all 
upper-level protocols. Errors and exceptions are offloaded 
to host-based upper-level software to manage. 

Tachyon High-Level Design Goals 

The Tachyon designers made several high-level design deci- 
sions early in the project. The primary design goal was to 
deliver sustained, full-speed gigabit performance while im- 
posing the minimum impact on host software overhead. To 
accomplish this. Tachyon supports all Fibre Channel classes 
of service (see article, page 94 1, automatically acknowl- 
edges inbound frames for class 1 and class 2. handles 
NL_Port and N_Port initialization entirely in hardware, man- 
ages concurrent inbound and outbound sequences, and uses 
a messaging queue to notify the host of all Completion infor- 
mation. To offload networking tasks from hosts. Tachyon is 
designed to assist networking protocols by supporting IP 
checksums and two different modes for splitting network 
headers and data. 

The second major design goal was that Tachyon should sup- 
port SCSI encapsulation over Fibre Channel ( known as 
FCP). From the beginning of the project, Tachyon designers 
created SCSI hardware assists to support SCSI initiator 
transactions. These hardware assists included special queu- 
ing and caching. Early in the design, Tachyon only sup- 
ported SCSI initiator functionality with its SCSI hardware 
assists. It became evident from c ustomer feedback, how- 
ever, that Tachyon must support SCSI target functionality as 
well, so SCSI target functionality was added to Tachyon 
SCSI hardware assists. 

Tachyon Feature Set 

To lake advantage of Fibre Channel s high performance. 
Tachyon:" 

• Provides a single-chip Fibre Channel solution. 

• Manages sequence segmentation and reassembly in hard- 
ware. 

• Automatically generates acknowledgement (ACK) frames for 
inbound data frames. 

• Automatically intercepts and processes ACK frames of out- 
bound data frames. 

• Processes inbound and outbound data simultaneously with 
a filll-duplex architecture. 

• Allows Chip transaction accesses to be kept at a minimum 
by means of host-shared data structures. 

To provide the most flexibility for customer applications. 
Tachyon: 

• Supports link speeds of 1063, Kft, and 266 Mbaud 

• Supports Fibre Channel class 1, 2, and 8 serv ices. 

• Supports Fibre Channel arbitrated loop i FC-AL), point-to- 
point, and fabric (crosspoinl switched) topologies. 

• Prov ides a glueless conned ion to industry-standard physi- 
cal link modules such as gigabaud link modules. 
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Supports up to 2K-byte frame payloacl size for all Fibre 
Channel classes of service. 

.Supports broadcast transmission and reception of FC-AL 
frames. 

Allows time-critical messages lo bypass the normal traffic 
waiting for various resources via a low-latency, high-priority 
outbound path through the chip. 

Provides a generic 32-bit midplane interface — the Tachyon 
system interlace. 

To provide support for customer nel working applications. 
Tachyon: 

Manages I he protocol for sending and receiving network 
Sequences over Fibre ( 'hannel. 

Provides complete support of networking connections. 
Computes exact checksums lor outbound IP packets and 
inserts them in the data stream, thereby offloading the host 
of a very compute-intensive task. 

Computes an approximate checksum for inbound IP pack- 
els dial partially offloads the checksum task from the host. 
( 'onlains hardware header/data .splitting for inbound SNAP/ 
IP sequences. 

To provide support for customer mass storage applications, 
Tachyon: 

Supports up to 1(>.3S4 concurrent SCSI I/O transactions. 
< 'an be programmed lo function as either an initiator or a 
target. 

Assists | he protocol for peripheral l/< > transactions v ia SCSI 
encapsulation over Fibre Channel (FCP). 

To reduce host software support overhead. Tachyon: 
Allows chip transaction accesses to be kept al a minimum 
by means of host-shared memory data structures. 
Manages interrupts lo one or zero per sequence. 
Performs FC-AL iniiiali/.ation wilh minimal host interven- 
tion. 

To provide standards compliance. Tachyon: 
Complies wilh Fibre Channel System Initiative (FCSI) pro- 
files. 

Complies with industry-standard M1H-II network manage- 
ment. 

To ensure reliability. Tachyon: 

Supports parity protection on its inlernal dala paih. 

Has an estimated MTBF of 1.3 million hours. 

Fabrication 

Tachyon is fabricated by LSI Logic Corporation using a 
0.5-uni 3.3V CMOS process. LCB500K. The chip dissipates 
just under 4 watts and is contained in a 208-pin MQHAD 
package with no heat sink. 

Tachyon Functional Overview 

The host interface of the Tachyon chip is a set of registers 
used for initialization, configuration, and control and a set of 
data structures used for sending and receiving data and for 
event notification. This interface is very flexible and allows 
the customer to design an interface lo Tachyon thai best 
meets the capability, performance, and other requirements 
of a specific application. 



Transmitting a Fibre Channel Sequence 

Ti i transmit an oulbound sequence (see Fig. 4), the host 
builds several data structures and sets up the data lo be 

transmitted, a data structure called the outbound descriptor 

block is built first. The outbound descriptor block provides 
much of the information Tachyon needs to send a sequence. 
The outbound descriptor block points to a data structure 
called the crteiided descriptor block, which points to data 
buffers containing I he dala for the sequence. The host then 
creates the Tachyon header structure, which contains im- 
portant Fibre Channel-specific information such as which 
Fibre Channel class pf service to use during sequence trims- 
mission. The host sets up the oulbound descriptor block to 
point to the Tachyon header structure. The host then adds 
the outbound descriptor block to the outbound command 
queue. 

When Tachyon sees the new entry in I he oulbound command 
queue, il gels the oulbound descriptor block from host 
memory via DMA. As Tachyon reads I he Tachyon header 
structure to send the first frame of I he sequence, il copies 
the header S t ructure to internal registers for use in generating 
Fibre Channel headers For subsequent frames. 

If this is class 1 service, after sending the first frame, Tachyon 
waits until it receives the ACK for the first frame of the se- 
quence before continuing. Tachyon then inserts an identifier 
value, called the irspoiider e.rcltmtue identifier (RXJD), 
which is returned in the ACK, into the Fibre Channel header 
on all subsequent frames of this sequence. Tachyon contin- 
ues It) transfer dala from the hosl via DMA in frame-sized 
blocks and sends I he frames with headers automat ically 
generated from the previously stored header. 

Tachyon keeps track of the frame count for the sequence. 
The Fibre Channel header for each frame contains an incre- 
mental count of the number of frames Iransmilled for die 
sequence along wtfli the relative position of thai frame with- 
in the sequence. As Tachyon sends the frames for the se- 
quence, il also I racks flow conlrol for the sequence using a 
Fibre Channel flow conlrol method called end-to-end credit 
(EE_Credit). EE_Credit determines the number of frames thai 
Tachyon can send to the remote destination without receiv- 
ing an ACK. Each time Tachyon sends a frame, EE_Credit 
decrements. Each time Tachyon receives an ACK from I he 
destination, EE_Credit increments. If EE_Credit goes lo zero, 
Tachyon stops transmitting frames and starts a watchdog 
timer called the ED_T0V tinier (error detect timeout value). 
The ED. T0V limer counts down until ACKs arrive. If ACKs ar- 
rive, Tachyon resumes transmission. If the ED_T0V timer ex- 
pires, Tachyon sends a completion message to the host indi- 
cating that the sequence has timed out. 

Once Tachyon has transmitted the last frame of a sequence 
and received all of the ACKs for the sequence, il sends a com- 
pletion message to the host via the inbound message queue. 
This tells ihe hosl that it can deallocate all memory associ- 
ated with this oulbound descriptor block and inform any 
processes wailing on iis completion. If a sequence terminates 
abnormally. Tachyon will nolify the host of the error in the 
completion message. 
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Receiving a Fibre Channel Sequence 

Fig. 5 shows an overview of the receive process. To enable 
Tachyon to receive data, the host first supplies Tachyon 
wilh two queues of inbound buffers. Two inbound queues 
are required because single-frame sequence reception and 
muliiliame sequence reception are handled independently. 
Tachyon needs minimal resources to receive a single-frame 
sequence, but for multiframe sequences the chip needs to 
use additional resources to manage the reassembly of 
frames. Because of this resource demand. Tachyon can reas- 
semble only one incoming multiframe networking sequence 
at a time. Tachyon supports the reception of single-frame 
sequences while reassembling a multiframe sequence ftib 
process allows a host to receive short sequences while 
Tachyon is reassembling a longer incoming sequence. 

Single-Frame Sequence Reception. The hosts uses the single- 
frame sequence buffer queue to inform Tachyon of the loca- 
tion of host-based buffers that Tachyon should use to re- 
ceive sequences contained within a single frame. As 
Tachyon receives a single-frame sequence, it places the en- 
tire sequence, which includes the Tachyon header structure 
followed by the sequence data, in the buffer defined by the 
address from the single-frame sequence buffer queue. If the 
sequence Is laager than one buffer si/.e, the remaining data 
of the Sequence is packed into the next buffers, as required, 
until all of the sequence is stored. Next, Tachyon sends an 
inbound_sfs_completion message to the host via the inbound 
message queue and generates an interrupt to the host. 



Fig. 4. Transmit process overview. 

Multiframe Sequence Reception. The host uses ihe multiframe 
sequence buffer queue to inform Tachyon of the location of 
host-based buffer's that Tachyon should use to receive anil 
reassemble incoming data that has been split into an arbi- 
trarily hu ge number of frames. When the first frame of a 
new sequence arrives, Tachyon copies the Tachyon header 
structure into the beginning of the next available multiframe 
sequence buffer. Tachyon packs the data payload of the 
frame into the next buffer following the buffer with the Ta- 
chyon header structure. As each new frame arrives, Tachyon 
discards the Fibre Channel header information and sends 
the data to the host. Tachyon packs this dala into each of 
the buffers on the multiframe sequence buffer queue, obtain- 
ing a new buffer when the current buffer is full, until (he 
entire sequence is Stored Once all the frames arrive and the 
sequence is reassembled in memory, Tachyon notifies the 
host that the entire sequence has been received by generat- 
ing a completion message and placing il into Ihe inbound 
message queue. Tachyon then generates a host interrupt to 
process the entire sequence. 

Tachyon can also handle multiframe sequences that are re- 
ceived out of order. When Tachyon detects an out-of-order 
frame, Tachyon generates a completion message that indi- 
cates the in-order portion of the sequence and Ihe last se- 
quence buffer used. Tachyon passes the completion mes- 
sage to the inbound message queue, but does not generate 
an interrupt until all frames of Ihe sequence are received. 
Next. Tachyon obtains the next available sequence buffer 



© Copr. 1949-1998 Hewlett-Packard Co. 



(Motor I U'wlHt-Packiml Journal 103 



Host-Based Data Structures 



IMO 



IMO Entry 



IMO Entry 



IMO Entry 











Tachyon 






Inbound 
Message 
Channel 





SFSBQ or 


SFSBQ or 
MFSBQ 
Entries 


r : 


r / 
/ 

/ • 


But Addi 


Queue 
Entry 


But Addr 
But Adrlf 


Queue 


But Addr 


Entry 




BulAddr 


Queue 




But Addr 


Entry 


But Addi 


- 




But Addr 





SFS orMFS 
BuHer 
Channel 




■ 




Inbound 
Data FIFO 

A 



Data BuHers 




Frame Manager 



T 



IMQ = Inbound Message Queue 
SFSBO = Single-Frame Sequence 

BuHer Queue 
MFSBQ = Multiframe Sequence 

Buffer Queue 
ISM = Inbound Sequence Manager 
OSM ■ Outbound Sequence Manager 



Link 



Fig. 5. Receive process overview, 



and copies the Tachyon header structure of this out-of-order 
frame into it. Then. Into Ihe next sequence buffer, it copies 
the data payload of this out-of-order frame. At this point, if 
the frames that follow the out-of-order frame are in order, 
Tachyon discards the Tachyon header structures and packs 
the data into the host buffers. Tachyon packs this data into 
each of the buffers on the multiframe sequence buffer 
queue, obtaining a new buffer when the current buffer is 
full, until Ihe entire sequence is stored. If another frame ar- 
rives out of order from the previous out-of-order portion, 
Tachyon generates a new completion message and the pro- 
cess is repeated. When it receiv es the final frame of the se- 
quence, Tachyon passes it to the host and generates a com- 
pletion message. At this time, Tachyon generates a host 
interrupt to process the entire sequence. With the informa- 
tion in each of the Tachyon header structures that Tachyon 
passed to the host for each in-order portion and the informa- 
tion in the completion messages, the host has enough infor- 
mation to reorder the out-of-order multiframe sequence. 

Tachyon Internal Architecture 

Tachyon's internal architecture is illustrated in Fig. 0. Each 
functional block in the architecture is described below. 

Outbound Message Channel. The outbound message channel 
block manages the outbound command queue. It maintains 
the outbound command queue as a standard circular queue. 



The outbound message channel informs the outbound se- 
quence manager block when an outbound command is wait- 
ing in host memory to be processed. When requested by the 
outbound sequence manager, the outbound message channel 
then reads one 32-byte entry from the outbound command 
queue and delivers it to the outbound sequence manager 
block for processing. 

High-Priority Message Channel. The high-priority message 
Channel block manages the high-priority command queue. 
The host can use the high-priority channel to send urgent 
single-frame sequences that need to bypass Ihe dedicated 
outbound command queue. For example, the host could use 
the high-priority command queue to send special Fibre 
Channel error recovery frames that might not otherwise be 
transmitted because of a blocked outbound command 
queue. The high-priority message channel maintains the 
high-priority command queue as a standard circular queue. 
The high-priority message channel informs the outbound 
sequence manager block when a high-priority outbound 
command is waiting in host memory to be processed. When 
requested by the outbound sequence manager, the high- 
priority message channel reads one entry from the high- 
priority command queue and delivers it to the outbound 
sequence manager block for processing. 
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Outbound Block Mover. The outbound block mover block's 
function is to transfer outbound data from host memory to 
the outbound sequence manager via DMA. II lakes as input 
an address/length pair from the outbound sequence manager 
block, initiates the Tachyon system interface bus owner- 
ships, arid performs i he most efficient number mid size of 
transactions on the Tachyon system interface bus to pull in 
the data requested. 

Outbound Sequence Manager. The outbound Sequence manager 
block is responsible for managing all outbound sequences. 
The outbound message channel, die high-priority message 
channel, and the S( 'SI exchange manager notify the out- 
bound sequence manager block when they have data to 
send. The outbound sequence manager must determine 
which channel has priorily. High-priority sequences have 
first priorily. bul the oulbound sequence manager deler 

mines priority between networking and sesi transactions 

using a fairness algorithm. Once priorily is determined. Hie 
oulbound sequence manager programs (he outbound mes- 
sage channel to retrieve a data sequence from host memory 
and segment it into individual frames for transmission. The 
oulbound sequence manager transmits the sequence, per- 
forms a TCP or I'DP-lype checksum on the sequence, veri- 
fies that each frame is acknowledged by I he receiving node, 
handles errors ifrequired, and sends a completion message 
to Hie host through the inbound message channel. 

Outbound Frame FIFO. The outbound frame FIFO buffers data 
before transmission lo prevent undernm. This FIFO is sized 
to hold one maximum-size frame. As Tachyon sends I he cur- 
rent frame onto the link, the outbound frame FIFO is simul- 
taneously Tilled with Hie nexl frame, maximizing oulbound 
performance and reducing latency. 

ACK FIFO. The ACK FIFO holds Fibre Channel class 1 and class 
2 ACKs until they can be senl out by I he frame manager. 

Frame Manager. The frame manager is Tachyon 's interface hi 
the physical link module. The frame manager implements 
the N_Port state machine described in the FC-PH specifica- 
tion and the loop stale machine described in the FC-AL 
specification. The frame manager can be configured lo sup- 
port link speeds of 1063, 631, and 2lifi megabits per second. 
It also implements initialization in hardware for both 
NL_Ports and N_Ports. 

The frame manager implements portions of the FC-1 and 
FC-2 specifications. Il is responsible for the FC-1 functions 
of transmitting and receiving Fibre Channel frames and 
primitives. Il calculates and verifies the CRC for frame dala, 
checks parily of the transmil data, and generates parity for 
the receive data. II generates primitives, encodes and re- 
ceives Fibre Channel frames and primitives, decodes 10-bii 
or 20-bit physical link module data, and implements the run- 
ning disparity algorithm in FC-1. The frame manager can be 
configured to generate interrupts lo I he host when certain 
link configuration changes occur to which the host musl 
respond. The interrupt process occurs as pan of NJ'on 
initialization and loop initialization and any lime the link has 
been disrupted. 

The ordered set and CRC generator encapsulates data into 
FC-1 frames, generates a 32-bit cyclic redundancy check 
(CRC), writes il into Ihe frame, and passes Ihe encapsulated 



dala lo Ihe 10B/20B encoder. The I0B/20B encoder convert* 
outbound lli-bii-wide dala into IwoK-bii pieces, each of 
which is encoded into a 10-bit transmission characier using 
ihe 8B/10B encoding algorithm. 

The 20B/I0B multiplexer is responsible for selecting Ihe 
proper width, either 10 bils or 20 bils. of Ihe datapath for 
the specific type of physical link module being used. The 
dala width and speed are specified by the parallel ED field of 
Ihe physical link module interface. 

The 10B/20B demultiplexer is responsible for receiving in- 
coming encoded dala. either 10 bils wide or 211 bits wide, 
from Ihe physical link module and packing il into 20 bits for 
decoding. The dala width and speed are specified by Ihe 
parallel ID Held of Ihe physical link module interface. 

The 20B/l(iB decoder is responsible for convening 20-bit- 
wide dala received from the 10B/20B demultiplexer into two 
K-bit data bytes. 

The elastic slot*' and smoothing block is responsible for 
retiming receiv ed data from the receive clock lo the trans- 
mit clock. The elastic store provides a flexible data F1F< I 
buffer between the receive clock and transmil clock do- 
mains. Receiver overrun and underrun can be avoided by 
deleting and inserting duplicate primitives from the elastic 
si ore as needed lo compensate for differences in receive 
clock and transmil clock frequencies (within specifications). 

The ordered sel processor and CRC checker block is re- 
sponsible for delecting incoming frame boundaries, verify- 
ing the cyclic redundancy check, passing the dala lo the 
inbound FIFO, mid decoding and recognizing pr imitive s, 

Inbound Data FIFO. The inbound data F1F< ) buffers frame dala 
while the frame manager verifies Ihe CRC. It also serves as 
high-av ailabilily temporary storage to facilitate the Fibre 
Channel How control mechanisms. This FIFO is sized lo 
hold a maximum of four 2K-byte frames (including headers). 

Inbound Sequence Manager. The unbound sequence manager 
is responsible for receiving and parsing all link control and 
link dala frames. It inleracts with Ihe SCSI buffer manager 
block lo process SCSI frames. The inbound sequence man- 
ager block is also responsible for coordinating the actions 
laken when a link reset is received from the frame manager 
block and for passing oulbound completions to the inbound 
data manager block. The inbound sequence manager also 
manages class I Fibre Channel connections. 

Inbound Data Manager. The inbound data manager routes 
incoming frames lo their appropriate buffers in host mem- 
ory, transferring SCSI FCP_XFER_RDY frames lo the SCSI ex- 
change manager, sending completion messages lo the in- 
bound message queue, and sending interrupts to Ihe 
inlernipl conlroller inside Hie inbound message channel. 

Inbound Block Mover. The inbound block mover is responsi- 
ble for DMA transfers of inbound dala into buffers specified 
by the multiframc sequence buffer queue, Ihe single-frame 
sequence buffer queue, the inbound message queue, or the 
SCSI buffer manager. The inbound block mover accepts an 
address from the inbound dala manager, then accepts Ihe 
subsequent dala stream and places the data into the location 
specified by Ihe address. The inbound block mover also 
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accepts producer index updates and interrupt requests from 
the inbound message channel and works with the arbiter to 
put the interrupt onto the Tachyon system interfac e bus. 

Inbound Message Channel. The inbound message channel 
maintains the inbound message queue. This includes supply- 
ing the inbound data manager with the address of the next 
available entry in the inbound message queue and generat- 
ing a completion message when the number of available 
entries in the inbound message queue is down to two. 

The inbound message channel also generates interrupts for 
completion messages, if nec essary, and handles message 
and interrupt ordering. The completion message must be in 
the host memory before the interrupt. The inbound message 
channel also handles interrupt avoidance, which minimizes 
the number of interrupts (strobes on the INT pin on the 
Tachyon system interface bus) asserted to the host for each 
group of completions sent to the host. 

Single-Frame Sequence Buffer Channel. The inbound single- 
fraiue sequence buffer channel manages the single-frame 
sequence buffer queue. It supplies addresses of empty 
single-frame sequence buffers to the inbound data manager 
and generates a completion message when the supply of 
single-frame sequence buffers runs low. 

Multiframe Sequence Buffer Channel. The inbound multiframe 
sequence buffer channel manages the multiframe sequence 
buffer queue. It supplies addresses of empty mullifraine 
sequence buffers to the inbound data manager and gener- 
ates a completion message when the supply of multiframe 
sequence buffers runs low. 

SCSI Buffer Manager. The S< SI buffer manager is responsible 
for supplying the inbound data manager w ith addresses of 
buffers to be used for inbound SCSI data frames. The SCSI 
buffer manager maintains a cache of Hi unique SCSI descrip- 
tor blocks. Each block contains eight S( SI buffer addresses. 
Depending upon the direction of the exchange, the origina- 
tor exc hange identifier (OXJD ) or the responder exchange 
identifier ( RX 10 ) of the current frame is provided by the 
inbound data manager block and is used to point to the cor- 
rect entry in the SCSI exchange stale table. 

SCSI Exchange Manager. In conjunction with the SCSI ex- 
change stale table data structure, the S( SI exchange iiianag 
er provides Tachyon with the hardware assists for S( SI l/( ) 
transactions. It converts SCSI exchange stale table entries 
to outbound descriptor block formal for the Outbound se- 
quence manager block's use. The SCSI exchange manager 

accepts sesi out] nd fcp_xfer_rdy frames fr the in- 
bound dala manager block. It then uses the OXJD or RXJO 
given in the frame as an offset into the stale table, reads I he 
entry, and builds the outbound descriptor block. 

Register Block. T he register block consists of control, config- 
uration, and status registers. These registers are used for 
initialization, configuration, control, error reporting, and 
maintenance of the queues used to transfer data between 
Ta< Iivon and the host. Each register is "12 bils wide and may 
be readable or both readable and writable by the host de- 
pending upon its function, 

SCSI Read/Write Channel. T he Si SI lead/write channel man- 
ages requests from the S( SI exchange manager and inter 
faces in i||e Tachyon system interface arbiter block. 



Tachyon SCSI Hardware Assists 

Tachyon supports SCSI I/O transactions (exchanges) by two 
methods. The first method uses host -based transaction man- 
agement. In this method, the host transmits and receives the 
various sequences using the general transmit and receive 
processes. By using the host-based transaction management 
method, Tachyon reassembles only one SCSI unassisted 
multiframe sequence at a time. The second method uses 
Tachyon's SCSI hardware assists. With this method. Tachyon 
assists the host transaction management through the use of 
a shared host dala structure called the S( "SI exchange state 
table. 

By using Tachyon's SCSI hardware assists, the host can con- 
currently reassemble up to 10.384 SCSI assisted sequences. 
Tachyon maintains an on-chip cache for up to Iti concurrent 
inbound transactions. Tachyon uses a least recently used 
caching algorithm to allow the most active exchanges to 
complete their transfers with the minimum latency. 

The protocol for SCSI encapsulation by Fibre Channel is 
known as FCP. Fig. 7 shows an overview of the FCP read 
exchange and Fig. S shows an ov erv iew of the FCP write 
exchange. The exc hanges proceed in three phases: com- 
mand, dala. and status. 

SCSI Exchange State Table. The SCSI exc hange stale table is a 
memory-based data structure. Access is shared between 
Tachyon and the host. The SCSI exchange state table is an 
array of :}2-byte entries. The starting address of the table is 
programmable and is defined by the SCSI exchange state 
table base register. The length of the table is also program- 
mable and is defined by the SCSI exchange stale table 

length register. Each used table entry corresponds to a cur- 
rent SCSI exchange, or I/O operation. Each entry Contains 
two kinds of information: information supplied by Ihe host 
driver for Tachyon to manage the exchange, and informaiion 
stored by Tachyon in Hack Ihe current stale of the ex- 
change. For initiators in SCSI write transactions, the out- 
bound S( SI exchange state table entries contain informa- 
iion indicating where outbound dala resides in memory and 
w hat parameters to use in the transmission of that dala on 
the Fibre Channel link. F6T initiators in SCSI read transac- 
tions, the inbound SCSI exchange siale table entries contain 
infornialion indicating where inbound dala is to be placed in 
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memory. SCSI exchange state table entries are indexed by 
an exchange identifier (XJD) — either the originator ex- 
change identifier ( OXJD) or the responder exchange identifi- 
er (RXJD). In an initiator application, the OXJD provides the 
index into the SCSI exchange stale table, hi a target applica- 
tion, the RXJD provides the index into the SCSI exchange 
siaie table. 

FCP Read Exchange — Tachyon as an Initiator. Fig. 9 shows the 
FCP read exchange host data structures lor an initiator Ta- 
chyon. For the initiator host to receive inbound SCSI data, it 
selects a valid OXJD value that points to an unused location 
in the SCSI exchange state table. The OXJD value identifies 
this particular exchange. Using the OXJD value, the initiator 
host builds a data structure called mi inbound SCSI ex- 
change state table entry. The inbound SCSI exchange state 
table entry includes the address of the SCSI descriptor 
block. The SCSI descriptor block defines the host buffers 
that Tachyon will use to store the received read data. 

In lite command phase, once the host creates the inbound 
SCSI exchange state table entry, it creates an FCP_CMND for 
an FCP read exchange. The initiator Tachyon sends the 
FCPJ^MND to the target via the outbound command queue. 

hi the daia phase, the initiator Tachyon may receive an 
FCP_XFER_RDY from the target. This is an optional step for an 
initiator in an FCP read because the data frames contain all 
the information needed to process them. When Tachyon 



receives the optional FCPJ<FER_RDY from the larget, it ac- 
knowledges the frame if appropriate and discards the 
FCPJ<FER_RDY. As each data frame is received, the SCSI ex- 
change manager uses the OXJD to access the appropriate 
inbound SCSI exchange state table entry for the address of 
the SCSI daia buffer. The SCSI descriptor block and the rela- 
tive offsel of the data frame determine where data is to be 
placed in host memory. Tachyon maintains an internal cache 
of 16 inbound SCSI exchange stale table entries. If the SCSI 
exchange stale table informal ion associated with the re- 
ceived frame is not in cache, Tachyon writes the least re- 
cently used cache entry back to I he host SCSI exchange 
state table. Tachyon then fetches into cache Ihe inbound 
SCSI exchange state table entry associated with the re- 
ceived frame and transfers the read data to host memory via 
DMA. The initiator Tachyon automatically handles both 
single and multiple data phases for inbound data transfers. 

In the status phase, when Ihe data phase is complete, the 
initiator Tachyon receives an FCP_RSP from Ihe target. The 
t&JVSP- is a Fibre Channel information imit that contains 
status information that indicates that the SCSI exchange has 
completed. The initiator Tachyon passes the FCP_RSP to the 
host via the single-frame sequence channel and sends a com- 
pletion message to the initiator host. This informs the initia- 
tor host that the exchange is completed. 

FCP Read Exchanges — Tachyon as a Target. For FCP road ex- 
changes for the target Tachyon. SCSI hardware assists are 
not used. Fig. 10 shows the read exchange target host data 
Struct tires. 

hi the command phase, the larget Tachyon receives an 
FCP_CMND for an FCP read from the initiator and sends the 
FCP_CMND to the target host via the single-frame sequence 
channel. If configured to automatically acknowledge, the 
target Tachyon immediately returns an ACK (for class 1 and 
class 2) lo Ihe initiator. The target host selects a valid, un- 
used RXJD value. The RXJD is placed into the header of the 
ACK and sent \ia the high-priority command queue. 

In the data phase. Ihe larget host builds an outbound des- 
criptor block that contains the extended descriptor block 
address. The target host builds an extended descriptor block 
that defines where the read data is located in the target host 
memory. The target host may send an FCPJ<FER_RDY to the 
initiator host to indicate that it is ready to send the re- 
quested data. The target Tachyon sends the FCPJ<FER_RDY(s) 
wilh the appropriate RXJD value to the initiator Tachyon. 
I sing the outbound command queue, the target Tachyon 
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then semis I he appropriate SCSI read data to the initiator via 
the outbound command queue. 

In the status phase, the target Tachyon sends an FCPJ1SP to 
the initiator to indicate that the exchange has completed. 

FCP Write Exchange — Tachyon as an Initiator. Fig. II shows the 
FCP write exchange initiator host data structures. For the 
initiator host to perform an outbound data transfer, it selects 
an unused SCSI exchange state table entry whose index will 
be used as the OXJD value. Csing the OXJD value, the initia- 
tor host builds an outbound SCSI exchange state table entry. 
The outbound SCSI exchange state table entry' includes in- 
formation about the frame si/.e, 1 1 »* - Fibre Channel class, and 
writable fields that the initiator Tachyon uses to manage the 
SCSI transfer. The outbound SCSI exchange slate table entry 
also contains a pointer to the extended descriptor block that 
contains pointers to the data to be sent. 

In the command phase, once the host creates the outbound 
SCSI exchange state table entry, the host creates the 
FCP_CMND for an FCP write exchange. The initiator Tachyon 
sends the FCP.CMND to the target via the outbound command 
queue. 

In the data phase, when the initiator Tachyon receives the 
FCP.XFER.RDY from the target, it uses its SCSI hardware as- 
sist and manages the data phase for this FCP,XFER_RDY inde- 
pendent of the host. Tachyon uses the informal ion in lite 
SCSI exchange stale table and the FCPJ(FER_RDY to build an 
OUtbOtmd descriptor block to be sent through the outbound 
stale machine. If the outbound sequence manager is busy, 
the SCSI exchange stale machine adds the request to a 
linked list of outbound transactions wailing for transmis- 
sion. As the OUtbound sequence manager becomes available 
to processa SCSI transfer, the SCSI exchange stale manager 
dequeues a waiting transaction and passes it td the out- 
bound sequence manager The outbound sequence manager 
transmits the write data to the targe) Tachyon. 



Fig. 10. P P read exchange target 
hOSt data structures. 

If this FCP_XFER_RDY is part of a mtdtiple-data-phase transfer, 
the initiator Tachyon passes litis FCP_XFER_R0Y as a single- 
frame sequence to the initiator host along with a completion 
message. The initiator host is responsible for managing the 
tlata phase for this multiplc-data-phase transfer by using the 
general sequence moving services. The OXJD field in the 
FCP,XFER_RDY is an index into the SCSI exchange state table 
and identifies the appropriate outbound SCSI exchange 
state table entry' 'hat points to the extended descriptor 
block in which the write data is locaied. Using the informa- 
tion in the outbound SCSI exchange state table entry, the 
initiator host builds an outbound descriptor block. The initi- 
ator Tachyon uses the outbound descriptor block to trans- 
mit the write data to the target. 

In the status phase, after the tlata phase completes, the initi- 
ator Tachyon receives an FCP_RSP from the target- The initia- 
tor Tachyon passes the FCP.RSP to the host and sends a com- 
pletion message to the initiator host. This informs the 
initiator host thai the exchange has completed. 

FCP Write Exchange — Tachyon as a Target. Pig IU show s the 
F( P wrile exchange target host data structures. 

In the command phase, the large! Tachyon receives an 
FCP_CMND for an FCP wrile from the initiator. If configured 
to do so, the target Tachyon Immediately returns an ACK to 
the initiator for class 1 and class 2. If Tachyon is not con- 
figured to return an ACK. the target host is responsible for 
sending the ACK. The target host selects a valid RXJD value, 
places the RX ID ilttO the ACK header and sends Hie ACK via 
the high-priority command queue. 

In the data phase, the targe! host selects an unused SCSI 
exchange State lable cnlry whose index will be the RXJD 
value. Using the RXJD value, the large! host builds the in- 
bound S( SI exchange slale lable entry thai points to the 
S( SI descriptor block. The SCSI descriptor block contains 
as many buffer addresses as necessary to receive the data. If 



T 



SEST 



OX 10 



SEST Entry 



SEST Entry 



SEST Entry 



Outbound 
SEST Entry 



SEST • SCSI Exchange State Table 
EDB ■ Extended Descriptor Block 




EOB 



Butter Addreis 



Butler length 



Butler Address 



Butter Ungth 



Bu'lci Aditreis 



Additional 
A/L Pairs 



Data Butters 




SCSIDnla 



SCSI Data 



Fig. It. !•'< IP wrile e.vimiigr itiiiia- 

tot haul data structure*, 



© Copr. 1949-1998 Hewlett-Packard Co. 



I H-tnliei 111! II '.Hewlett i';l<k:ilil .lnurii;<l 109 



HXJD 



T 



SEST 



Inbound 
SEST Entry 



T 



SEST Entry 
SEST Entry 



SEST Entry 



A, 



SEST = SCSI Exchange State Table 
EDB = SCSI Descriptor Block 
000 = Out of Order 




SOB 

000 Reassembl 


y 


Data Buffers 


Buffer Address 
Sutler Addruss 


. 1 — 1> 


SCSI Data 


Buffer Address 






• 
• 


~u 


SCSI Data 

erci n-.i-. 


• 

Buffer Address 




ouoi uata 
SCSI Oata 



Fig. 12. FCP write exchange Nirgr-l 
host data structures. 



the target host has enough buffers and is ready lo receive all 
of the data from the initiator, the host programs the inbound 
SCSI exchange state table entry and the largel Tachyon 
sends the FCP_XFER_RDY to the initiator via the outbound 
command queue. The initiator will send the data when it is 
ready. 

The target Tachyon checks the RXJD of the data frame to 
locate the appropriate inbound SCSI exchange state table 
entry. The inbound SCSI exchange state table entry helps 
Tachyon determine exactly where within the buffers the 
data is to be placed. When the last dala frame is received, 
the target Tachyon sends a completion message to the target 
host to inform the target host that all frames for the SCSI 
sequence have been received. 

In the status phase, the target host sends an FCP_RSP lo the 
inil later via the outbound command queue. 

Tachyon System Interface 

The Tachyon system interface describes the backplane pro- 
tocol for the Tachyon chip. It is a flexible backplane inter- 
face that allows customers lo interface to Tachyon using 
many existing backplane protocols, including I*CI. MCA, 
S-bus, EISA, VME, and Hewletl -Packard's High-Speed Con- 
nect (HSC) bus. The Tachyon system interface is capable of 
I00-Mbyte/s data transfers. Fig. 13 shows the Tachyon sys- 
tem interface signals. 

The Tachyon system interface provides a basic transaction 
protocol that uses two major operalions: write transactions 
and read transactions. Every transaction has a master and a 
responder. If the host is the master of a transaction. Tachyon 
is the responder in thai transaction, and vice versa. 

The master of a t ransaction drives an address and transac- 
tion type onto the TAD| 1 and TYPE[ ] buses, respectively, while 
asserting AVCS^L to indicate the start of the transaction. If 
Tachyon masters a transaction, the host, as the responder, 
uses READY_L as its acknowledgment signal. Similarly, if the 
host masters the transaction. Tachyon, as the responder, 
uses READY_L as its acknowledgment signal. A Tachyon sys- 
tem interface bus master has the choice of using one-word, 
two-word, four-word, or eight-word read and write transac- 
tions on the Tachyon system interface bus. 

Tachyon System Interface Streaming 

To maximize performance, the Tachyon system interface 
allows the host lo configure the length of Tachyon's bus ten- 
ancy. When Tachyon obtains mastership of the Tachyon sys- 
tem interface and has more than one transaction to perform. 



Tachyon may extend its bus tenancy and perform several 
Tachyon system interface transactions (up to the maximum 
programmed limit.) before releasing mastership. Table I 
shows how streaming increases performance over non- 
si reaming. 

Table I 

Tachyon Performance Savings with Streaming 
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Tachyon Host Adapter Requirements 

A generic Fibre Channel host hits adapter board using the 
Tachyon chip contains the following: 

• Backplane Connector. Conne»-ts the backplane interface 
chip to the system bus. 

• Backplane Interface Chip. Enables the connection of the 
Tachyon system interface bus to PCI, EISA, HP-HSC or 
other bus. 

• Tachyon Chip. HP's Fibre Channel inlerface controller 

• Physical Link Module. Tachyon interfaces to many GLM- 
compiiant physical link modules currently in the market- 
place. Types of modules include: 

lOttJ-Mbit/s DB9 copper connectors for distances up to 
30 meters. 

1063-Mbil/s shortwave laser physical link modules for 
distances up to 500 meters. 

1003-Mbit/s longwave laser physical link modules for 
distances up to 10 kilometers. 

2(>6-Mbit/s shortwave laser physical link modules for 
distances up to 2 kilometers. 

A block diagram of a typical host bus adapter is shown in 
Fig. 14. An HP-HSC Fibre Channel adapter is shown in 
Fig. !•">. This adapter was developed by IIP to provide Fibre 
Channel connection to the IIP 9(11)0 K-Class servers 3 for last 
networking and mass storage. 



|a| 




(b) 

Fig. 15. («) ill' use Fibre Channel adapter, side \ M HP HSC 

Fibre Channel adapt er, side B. 
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Fig. 14. Block diagram of a typical host adapter board. 
Development Tools 

Effective tools were key to the success of the Tachyon 
chip. 1 ' The following tools were used in the development 

project 

• Cadence Verilog-XL Turbo was used for interactive and 
batch Register Transfer Language (RTL) simulations, gate 
functional simulations, and dynamic simulation. 

• Chronologic Verilog Compiled Simulator (VCS) was used for 
batch RTL simulations. 

• Quad Motive was used for static liming analysis. 

• Synopsys was used for chip .synthesis. 

• Veritools Undertow was used as a waveform viewer. 

• Inter-IIDL Verilint was used to check syntax and semantics 
for RTL code. 

• SIL Synth was used to manage and launch synthesis jobs. 

• History Management System (I IMS),-' written by Scott A. 
Kramer, was used as a revision cont rol system. 

• LSI Logic Corporations Concurrent Modular Design Envi- 
ronment (CMDE) was used for lloorplanuing bonding, delay 
calculation, and layout. 

• Hewlett Packard Task Broker'' was used to distribute jobs 
to the various compute engines. 

Vcrificat ion Environment 

The verification environment used for Tachyon was very 
sophisticated and automated The Tachyon chip model (as 
either a Verilog RTL code or a gate-level netlist ) was tested 
in simulation using Verilog's programming language inter- 
lace capability. Test modules written in C or in Verilog pro- 
vided stimulation to the Tachyon chip. Other test modules 
then verified the functionality of the chip and reported 
errors. 

Conclusion 

The Tachyon Fibre ( 'hannel interface controller provides a 
high-performance, single-chip solution for mass storage, 
clustering, and networking applications. Tachyon has been 
selected by many other companies as the cornerstone of 
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their Fibre Channel product designs. As an understanding of 
the capabilities of Fibre Channel technology grows in the 
marketplace. Tachyon is expected to be present in a large 
number of new Fibre Channel products. 
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